From chris.hall@highwayman.com Sun Sep 2 03:48:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7921F899A; Sun, 2 Sep 2012 03:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.215 X-Spam-Level: X-Spam-Status: No, score=-98.215 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_50=0.001, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7flxRHF+xSLK; Sun, 2 Sep 2012 03:48:28 -0700 (PDT) Received: from smtp.demon.co.uk (mdfmta010.mxout.tch.inty.net [91.221.169.51]) by ietfa.amsl.com (Postfix) with ESMTP id 023A321F8995; Sun, 2 Sep 2012 03:48:27 -0700 (PDT) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id 32211400268; Sun, 2 Sep 2012 11:48:26 +0100 (BST) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id CDC04400250; Sun, 2 Sep 2012 11:48:25 +0100 (BST) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tch.inty.net (Postfix) with ESMTP; Sun, 2 Sep 2012 11:48:25 +0100 (BST) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1T87j6-0003kI-MO; Sun, 02 Sep 2012 10:48:24 +0000 From: "Chris Hall" To: References: <066901cd874e$fa0605f0$ee1211d0$@highwayman.com> In-Reply-To: Date: Sun, 2 Sep 2012 11:48:19 +0100 Organization: Highwayman Message-ID: <07d101cd88f8$7a2c8f60$6e85ae20$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJn9OxjujSjCTsYygfO8NLLdB3mFwInuPc+li4fbGA= Content-Language: en-gb X-MDF-HostID: 19 Cc: 'idr wg' , grow@ietf.org Subject: Re: [Idr] [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 10:48:29 -0000 Rob Shakir wrote (on Fri 31-Aug-2012 at 19:00 +0100): ... > Thanks for this detailed analysis. It is akin to something that > Alton Lo and I worked through whilst defining the critical and > semantic error types (and suggested inclusions). > > If you'll forgive me for responding to some particular points, I > feel this might aid the discussion and positioning. I have added > comments in-line marked [rjs]. > > On 31 Aug 2012, at 09:02, Chris Hall wrote: > > > This is all pretty low level stuff. I can hear an argument that > > the requirements document is not the place for this level of > > detail. However, without a more precise understanding of how > > broken attributes may be parsed, requirements for how to deal > > with them are hard to specify and to interpret. > [rjs]: What this draft intends to do is provide expectations, > requirements and context for error handling in BGP-4, based on > current deployments (and operator's experience). It also puts > forwards requirements for how each type of error is reacted to in a > broad sense. Essentially, where it came from is defining why > amending the error handling behaviour is required, and providing a > framework against which we can hang the different developments that > are being discussed in IDR, such that they meet the operational > challenges that come from amending this behaviour and form a > complete set of solutions to meet the problem space. > > [rjs]: I think the error handling solutions draft (draft-ietf-idr- > error-handling) should take the work that we have done within IDR > and GROW in this draft and build the next level of detail, which I > think that you've made a great start to. I would like to try and > keep the requirements draft such that it can be referred to by both > existing attributes, and future ones. I agree that the Requirements want to be at as high a level as possible. Requirements based on experience are good, too. The issue I have is that the draft seems to go into too much detail in some areas, and not enough in others. Looking at Sections 2.1.1: at a high level, a Critical error is one for which tearing down the session is unavoidable. That is deemed to be when the receiver cannot be sure that they have extracted from a broken UPDATE all the NLRI to which it refers (yes ?). If you don't have the NLRI, you are stuck. If you have the NLRI, it may be possible to contain the error so that it affects only those NLRI (for example, by "treat-as-withdraw"). If you have the NLRI and enough (however defined) valid (however defined) attributes, it may be possible to update the NLRI, perhaps partially or temporarily. [Actually, I'm not sure that is complete. As observed elsewhere in the draft, a given BGP session may be carrying a number of AFI/SAFI and possibly a number of separate VPN. So for some purposes perhaps it's not necessary to be able to identify all the NLRI to which the UPDATE applies, only the AFI/SAFI or VPN to which the UPDATE applies. If so, then perhaps there is a Requirement for Critical errors to be handled on a per AFI/SAFI and per VPN basis -- that is, a "semi-Critical" error which tears down a self-contained part of the session. I'm not sure whether the definition of a Critical BGP Error allows for this or not, depending on how one interprets "Errors Parsing the NLRI".] Staying with the high level requirements, if an error is to not be Critical, it appears one needs: (a) to be able to extract the NLRI (or AFI/SAFI etc ?) with some degree of certainty. (b) to have ways of dealing with that NLRI in ways that do not affect other NLRI learned in the session unnecessarily, and which do not cause unacceptable side effects. (c) to be able to extract some attributes with some degree of certainty, and be able to judge when proceeding to process an UPDATE with an incomplete or damaged set of attributes will yield sufficiently valid routes. (d) to have mechanisms to signal the problem so that the root cause(s) can be addressed and possibly to trigger other (e.g. operational) responses. for which there could usefully be some discussion of "degree of certainty", "affect...unnecessarily", "unacceptable side effects", "sufficiently valid" and so on -- from a routing information and an operational perspective. For example, if "treat as withdraw" is performed, but the receiver has not (for whatever reason) been able to extract all the NLRI sent, the receiver is left with some stale (possibly invalid) routes; that may be acceptable because the alternative (tearing down the session) is worse, or because other (operational/protocol) mechanisms will kick in to clean up... and so on. The draft appears to say that anything which is not a Critical Error is a Semantic one -- or vice versa. This appears to assume that in the parsing of attributes, an error in one attribute does not affect any other attribute -- in particular, that an error in a not-NLRI attribute does not affect the ability to reliably (enough ?) extract the NLRI. To support that, I think the document would need to go down into the nuts and bolts of the parsing mechanics. (Section 2.1.2 starts with "Where a BGP message is correctly formed"... I assume that means that the Message, Withdrawn Routes and Total Path Attribute Lengths are consistent, and the Marker is 'all-ones' ?) This is what I mean by both too much and too little detail. The high level requirement is to be able to extract NLRI (etc); whatever the issues in doing so are, they are perhaps at too great a level of detail for this document. On the other hand, the discussion of Semantic Errors does not go into sufficient detail to support the requirements which flow from (the apparently assumed) ability to parse attributes separately. Where an UPDATE does not contain a Critical error, the receiver has (by definition) the NLRI (which it believes it has received correctly) and perhaps some Attributes. What the receiver then does may depend on its confidence in what it has managed to extract from the broken message. All of that can be left as an exercise for implementers. The requirements should focus on the implications from a routing/operational perspective and offer some criteria for acceptable behaviour. The current standard requires (for safety) that any error invalidates everything learned in the Session. One step from there is that some errors only invalidate all the NLRI referred to in the erroneous UPDATE message -- which (for safety) discards all attributes in the message. A further step is that some errors do not invalidate the NLRI in the erroneous UPDATE message, but processing proceeds with some subset of the attributes. For my money, that further step is a giant step, and deserves to be covered at the Requirements level. [Another step is that some errors invalidate everything learned in the Session about a given AFI/SAFI or (possibly) VPN.] ... > [rjs]: Please note that the requirements draft does not present > distinctions such as recoverable and ignorable. We went around this > loop previously. I think that in some cases, some specific errors > may be handled by 'patching' or 'ignoring' specific errors. But > generically, these are exceptions - the requirements try and define > broader categories, if a particular attribute needs something else > (e.g., AS4_PATH may have information it can recover from other > attributes) then this can be handled in error handling solution > considerations of these attributes or as it is defined going > forward. I'm sorry to have missed the previous discussion. Suffice it to say that, as above, I think that Ignoring or Recovering (patching up) some errors is materially different to examining each attribute carefully and dumping the whole lot on the floor if any one is invalid. But this touches on the incompleteness (IMHO) of the classification. For me, one can consider a semantic error in an attribute only after establishing that it is (in my terms) correctly "framed". Once one has parsed a set of attributes, and concluded there is no reason to believe that some invalid attribute length has thrown the parser off track, then one can get into what to do with the contents of each attribute. I think the difficulty is (repeating myself, sorry) exactly illustrated by the question of what to do with an ATOMIC_AGGREGATE attribute which is apparently 421 octets long. At a requirements level, you may not wish to get into the detail of this. But as it stands, the draft classifies pretty much every way in which an attribute can be broken as a Semantic error. This seems to me to miss the important fact that an attribute is only an attribute once the Path Attributes part of the message has been parsed satisfactorily -- up to that point, the entire Path Attributes are a pretty random looking collection of octets. ... > [rjs]: The requirement the document makes is explicitly that not all > errors are defined as critical (if they were, the requirement > specified by section 3 would not be met, and we would stick with the > behaviour we have right now). The reason for a distinction between > critical and semantic is that there are certain errors that mean > that cannot be localised to certain NLRI. OK. Sure. We have Critical and Not-Critical errors. Not-Critical errors are those for which we can extract the NLRI. A key reason for not being able to extract the NLRI is encountering an error when parsing the Attributes. Some errors may suggest that the sender has gone barking mad, and it is not possible to say whether there are NLRI there to extract or not. Other errors may be less alarming. The given definition of Semantic errors does not distinguish. As above, the requirements could step back from the parsing issue, and specify only the need to reliably extract NLRI. And, if it is a requirement to proceed to process (as opposed to just invalidate) NLRI from a broken message, the requirements should specify the need to reliably extract a good enough subset of attributes to proceed with. At the very least, I suggest that Critical (severity of error) and Semantic (form of error) are orthogonal notions. > [rjs]: I hope you do not see these comments as dismissive of what > you have put together - I think that this is where operational and > implementation views diverge. My view is that I need to understand > what the impact to a service, the device and the network is during > these error conditions (and balance the risk of incorrectness > against the correctness of the protocol). From an implementation > perspective, clearly, one needs to understand exactly which > circumstances one can extract the NLRI, and the particulars of how > this is achieved. I would encourage discussion that falls into the > latter category such that we define the solutions draft to have the > relevant guidance where required. Comments on the former should > absolutely live in the requirements draft Sure. I am trying to make the case that where the Requirements touch on the implementation issues, it is going too deep. And, in lumping all kinds of errors together and deeming them to be Semantic errors, the issues there are obscured rather than brought into focus. If the Requirements were written without reference to the internal organisation of the BGP UPDATE message, that would be fine. As you say, what really matters is the operational impact of changes to the protocol which may include, inter alia: 1. some routes will be treated as "good" while others from the same source have been deemed invalid. This is the effect of, for example, "treat-as-withdraw". How much confidence can one have in the "good" routes, if the peer is sending a mixture of apparently valid and invalid stuff ? If a peer who sent a bunch of valid routes last week now sends a number of invalid ones, what do we think about the ones which remain "good" ? Should there be a mechanism to de-preference remaining "good" routes ? Is a response that has this effect required to be just the first step in a longer process, in which the cause of the error is dealt with ? In which case, can more risks be taken when selecting such a response ? 2. some routes will be treated as "good" which should be treated as invalid. This is the effect of not treating an error as Critical, but not identifying all affected NLRI. If this is not acceptable, then an implementation must take some care when deciding whether it has extracted all NLRI from a broken message. If there are degrees of acceptability, then an implementation would need to take a view... presumably based on some understanding of the likely operational impact ? Or there should be configuration knobs to twiddle ? 3. some routes will be treated as valid which would previously have been treated as invalid. If the rules for validating attributes are changed, then some routes might be accepted with a variety of issues with their attributes. If processing proceeds with a partial set of attributes, routing may be affected. If this is not acceptable, then an implementation must take great care here. While the question of which attributes and under what conditions this might happen is clearly an implementation issue, the acceptability of the result must be judged by its operational impact. Also important from an operational perspective may be how any new features to support better error handling are deployed. Clearly new code is involved. But if new capabilities and new code at both ends of an eBGP conversation are required, is that an issue ? Should new behaviour in BGP be required to be enabled by configuration, or enabled by default but with suitable override configuration options ? I am in violent agreement with you. The high level requirements are essentially operational ones. My suggestion is that the requirements would be improved by backing out of the discussion of the internal structure of BGP UPDATE messages. On the other hand, classifying errors in terms of what information is lost/preserved, would improve things. Such analysis might lead to requirements which can only be met by changes at the protocol/implementation level, and if so, more power to it, say I. [Those changes might be: (a) a greater separation of NLRI from Attributes, (b) more redundancy in the framing of attributes so that the parser can have greater confidence that it has identified all attributes sent, (c) a means to identify AFI/SAFI or VPN independent of the NLRI, even ?, (d) etc... in addition to the various other features mentioned in the draft for tearing down parts of a session, recovering parts of the RIB, signalling errors, monitoring etc. etc.] Thanks, Chris PS: section 2 refers to "analysis of incidents". Is there a collection somewhere one could take into consideration when making implementation decisions ? Is there evidence, for example, that well known attributes with invalid flags and/or lengths have been a problem in practice ? From jgs@juniper.net Fri Sep 7 12:27:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ECA21F8625 for ; Fri, 7 Sep 2012 12:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwEl7lzRxTDL for ; Fri, 7 Sep 2012 12:27:07 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 389CA21F8621 for ; Fri, 7 Sep 2012 12:27:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEpKiRskjjys2k7cDH1e3U0R+VJkBYWf@postini.com; Fri, 07 Sep 2012 12:27:06 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 7 Sep 2012 12:22:04 -0700 Received: from [172.16.13.202] ([172.16.13.202]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q87JM2h47242; Fri, 7 Sep 2012 12:22:02 -0700 (PDT) (envelope-from jgs@juniper.net) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Apple Message framework v1278) From: "John G. Scudder" Date: Fri, 7 Sep 2012 15:22:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5031BD5C.40007@ops-netman.net> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1278) Subject: [Idr] Fwd: Publication request: draft-ietf-sidr-pfx-validate X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:27:08 -0000 IDR folks, draft-ietf-sidr-pfx-validate has passed SIDR WG last call. It hasn't yet = been sent for IETF last call. The draft relates to BGP of course. If you = have any comments, please send them to the IDR list and cc the SIDR = list. Thanks, --John Begin forwarded message: > From: Chris Morrow > Subject: Publication request: draft-ietf-sidr-pfx-validate > Date: August 20, 2012 12:30:20 AM EDT > To: "sidr-chairs@tools.ietf.org" , = "sidr-ads@tools.ietf.org" , = "iesg-secretary@ietf.org" , = "draft-ietf-sidr-pfx-validate@tools.ietf.org" = >=20 > Note: > there are a few idnits that will be taken care of before final > publication (at the sure-to-exist IESG comments/updates period), none = of > the nits are dangerous. >=20 > -------------- pub rquest/shephard doc --------------- >=20 >=20 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why is > this the proper type of RFC? Is this type of RFC indicated in the = title > page header? >=20 > Proposed Standard >=20 >=20 > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: >=20 > Technical Summary: >=20 > Relevant content can frequently be found in the abstract and/or > introduction of the document. If not, this may be an indication that > there are deficiencies in the abstract or introduction. >=20 > "To help reduce well-known threats against BGP including prefix mis- > announcing and monkey-in-the-middle attacks, one of the security > requirements is the ability to validate the origination AS of BGP > routes. More specifically, one needs to validate that the AS number > claiming to originate an address prefix (as derived from the AS_PATH > attribute of the BGP route) is in fact authorized by the prefix > holder to do so. This document describes a simple validation > mechanism to partially satisfy this requirement." >=20 > Working Group Summary: >=20 > Was there anything in WG process that is worth noting? For example, = was > there controversy about particular points or were there decisions = where > the consensus was particularly rough? >=20 > There were several revisions (8) of this document, there was a fairly > lengthy discussion in several in-person meetings as well as on-list. = In > the end, all of the issues seem to have been dealt with. >=20 >=20 > Document Quality: >=20 > Are there existing implementations of the protocol? Have a significant > number of vendors indicated their plan to implement the specification? > Are there any reviewers that merit special mention as having done a > thorough review, e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If there was a > MIB Doctor, Media Type or other expert review, what was its course > (briefly)? In the case of a Media Type review, on what date was the > request posted? >=20 > To date, there are 2 implementations in vendor code, one of which > brought about the single IPR claim against this document. >=20 > Personnel: >=20 > Who is the Document Shepherd? Who is the Responsible Area Director? >=20 > The document shephard is: Chris Morrow (me) > The responsible AD is: Adrian Farrel (Galactic Policeman this week) >=20 > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready = for > publication, please explain why the document is being forwarded to the = IESG. >=20 > I read the document (several revisions), and believe it's in shape for > publication (minus the nits which should be handled in iesg commentary > time). >=20 >=20 > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? >=20 > I don't have any issues with the review done. >=20 > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that = took > place. >=20 > I don't think there are parts of the document which require > broader-perspective-review, aside from the normal iesg reviews. >=20 >=20 > (6) Describe any specific concerns or issues that the Document = Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is = uncomfortable > with certain parts of the document, or has concerns whether there = really > is a need for it. In any event, if the WG has discussed those issues = and > has indicated that it still wishes to advance the document, detail = those > concerns here. >=20 >=20 > I don't believe there are any specific concerns. >=20 >=20 > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP = 78 > and BCP 79 have already been filed. If not, explain why? >=20 >=20 > The authors brought forth the current IPR claim, that is the only one = known. >=20 >=20 > (8) Has an IPR disclosure been filed that references this document? If > so, summarize any WG discussion and conclusion regarding the IPR > disclosures. >=20 >=20 > Yes, there is an IPR disclosure. The WG has seen this and comments = were > made at an in-person meeting. There wasn't a blocking comment, = however. >=20 > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others = being > silent, or does the WG as a whole understand and agree with it? >=20 > WG consensus seems quite solid. >=20 > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) >=20 >=20 > no appeals or issues of grandeur were raised. >=20 >=20 > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the = Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. >=20 > The document authors are aware of the nits, and will fix them in iesg > review time. >=20 > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. >=20 >=20 > N/A >=20 >=20 > (13) Have all references within this document been identified as = either > normative or informative? >=20 > yes >=20 > (14) Are there normative references to documents that are not ready = for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? >=20 > no. >=20 > (15) Are there downward normative references references (see RFC = 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. >=20 >=20 > no >=20 >=20 > (16) Will publication of this document change the status of any = existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not = listed > in the Abstract and Introduction, explain why, and point to the part = of > the document where the relationship of this document to the other RFCs > is discussed. If this information is not in the document, explain why > the WG considers it unnecessary. >=20 > no >=20 > (17) Describe the Document Shepherd's review of the IANA = considerations > section, especially with regard to its consistency with the body of = the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC = 5226). >=20 > it seems consistent. >=20 > (18) List any new IANA registries that require Expert Review for = future > allocations. Provide any public guidance that the IESG would find = useful > in selecting the IANA Experts for these new registries. >=20 >=20 > n/a >=20 > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. >=20 > n/a >=20 > ------------------ end writeup -------------------- From shares@ndzh.com Tue Sep 11 11:18:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7121F8697 for ; Tue, 11 Sep 2012 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kMccC3qEBpr for ; Tue, 11 Sep 2012 11:18:33 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD621F8692 for ; Tue, 11 Sep 2012 11:18:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=66.236.51.34; Received: from SKH2012HPLT (unverified [66.236.51.34]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3600236-1945496 for multiple; Tue, 11 Sep 2012 14:18:20 -0400 From: "Susan Hares" To: Date: Tue, 11 Sep 2012 14:18:19 -0400 Message-ID: <001501cd9049$d2855c20$77901460$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CD9028.4B79FDB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2QSImaq3wS4966Q2GIO+o9IjiijA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr-chairs@tools.ietf.org Subject: [Idr] draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:18:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01CD9028.4B79FDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit idr wg: The WG has approved as WG draft: draft-gredler-idr-ls-distribution. The authors should submit this draft as: draft-idr-ls-distribution-00.txt. To the IPR question we had 10 agreements to IPR, and 1 "rather not, but approve". This means the WG will go forward with the draft with the IPR included. If you have concerns about IPR at this point, please contact the chairs. Also, we look for 2 implementations prior to approving a IDR standard for RFC publication. If you have coded this draft, and have experience to share - please send your experience to the IDR mail list. Also consider providing interoperability reports at the next IDR WG meeting in November. Thank you, Sue and John ------=_NextPart_000_0016_01CD9028.4B79FDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

idr = wg:

 

The WG has approved = as WG draft:

draft-gredler-idr-ls-distribution.

 

The authors should = submit this draft as: draft-idr-ls-distribution-00.txt. =

 

To the IPR question = we had 10 agreements to IPR, and 1 “rather not, but = approve”. This means the WG will go forward with the draft with = the IPR included. If you have concerns about IPR at this point, please = contact the chairs.

 

Also, we look for 2 = implementations prior to approving a IDR standard for RFC = publication.  If you have coded this draft, and have experience to = share – please send your experience to the IDR mail list.  = Also consider providing interoperability reports at the next IDR WG = meeting in November.

 

Thank = you,

 

Sue and John =

------=_NextPart_000_0016_01CD9028.4B79FDB0-- From shares@ndzh.com Tue Sep 11 11:25:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5A21F84E7 for ; Tue, 11 Sep 2012 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz7g-2ZHYtnh for ; Tue, 11 Sep 2012 11:25:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1F21F84D7 for ; Tue, 11 Sep 2012 11:25:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=66.236.51.34; Received: from SKH2012HPLT (unverified [66.236.51.34]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3600296-1945496 for multiple; Tue, 11 Sep 2012 14:25:23 -0400 From: "Susan Hares" To: Date: Tue, 11 Sep 2012 14:25:22 -0400 Message-ID: <003401cd904a$ce699ce0$6b3cd6a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CD9029.4758C030" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2QSr3asy3HNaPnQviiOARDEureJw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr-chairs@tools.ietf.org, idr-ads@tools.ietf.org Subject: [Idr] draft-gredler-idr-ls-distribution approved as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:25:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0035_01CD9029.4758C030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit idr wg: The WG has approved as WG draft: draft-gredler-idr-ls-distribution. The authors should submit this draft as: draft-idr-ls-distribution-00.txt. To the IPR question we had 10 agreements to IPR, and 1 "rather not, but approve". This means the WG will go forward with the draft with the IPR included. If you have concerns about IPR at this point, please contact the chairs. Also, we look for 2 implementations prior to approving a IDR standard for RFC publication. If you have coded this draft, and have experience to share - please send your experience to the IDR mail list. Also consider providing interoperability reports at the next IDR WG meeting in November. Thank you, Sue and John ------=_NextPart_000_0035_01CD9029.4758C030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

idr = wg:

 

The WG has approved = as WG draft:

draft-gredler-idr-ls-distribution.

 

The authors should = submit this draft as: draft-idr-ls-distribution-00.txt. =

 

To the IPR question = we had 10 agreements to IPR, and 1 “rather not, but = approve”. This means the WG will go forward with the draft with = the IPR included. If you have concerns about IPR at this point, please = contact the chairs.

 

Also, we look for 2 = implementations prior to approving a IDR standard for RFC = publication.  If you have coded this draft, and have experience to = share – please send your experience to the IDR mail list.  = Also consider providing interoperability reports at the next IDR WG = meeting in November.

 

Thank = you,

 

Sue and John =

 

------=_NextPart_000_0035_01CD9029.4758C030-- From jhaas@slice.pfrc.org Tue Sep 11 12:29:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9F21F8668 for ; Tue, 11 Sep 2012 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XnHQhpeXE7X for ; Tue, 11 Sep 2012 12:29:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07821F865B for ; Tue, 11 Sep 2012 12:29:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BE4DEC39E; Tue, 11 Sep 2012 15:29:58 -0400 (EDT) Date: Tue, 11 Sep 2012 15:29:58 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20120911192958.GD8139@pfrc> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org, "Jon Mitchell \(GNS\)" , "'John G. Scudder'" Subject: Re: [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:30:00 -0000 On Mon, Aug 20, 2012 at 10:43:09AM -0400, Susan Hares wrote: > IDR WG: > This is call for adoption of > draft-mitchell-idr-private-as-reservation-01 > as a working group draft, I support adoption of this draft as a working group document. I also believe the text in -01 has reached a level of maturity that once the "why would anyone want more private AS numbers" discussion has reached whatever conclusion it may that it is ready for last call. The one minor detail I'd like to see resolved is how IANA will choose to interpret AS 65535 based on this current draft. -- Jeff From jhaas@slice.pfrc.org Tue Sep 11 12:50:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3E21F8692 for ; Tue, 11 Sep 2012 12:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYQq8NU2d+lD for ; Tue, 11 Sep 2012 12:50:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CE14921F868A for ; Tue, 11 Sep 2012 12:50:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 38785C3A8; Tue, 11 Sep 2012 15:50:45 -0400 (EDT) Date: Tue, 11 Sep 2012 15:50:45 -0400 From: Jeffrey Haas To: Bill Fenner Message-ID: <20120911195045.GF8139@pfrc> References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1> <6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net> <44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1> <283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net> <44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081307A42614@tlvmail1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:50:49 -0000 Responding to a somewhat stale thread: On Wed, Jul 25, 2012 at 04:21:50PM -0700, Bill Fenner wrote: > > What is the problem with expanding the table to include all required BGP > > information? If your concern is memory utilization, at the risk of stating > > the obvious let me say that MIB structure doesn?t necessarily prescribe the > > internal database structure, meaning you can always choose a more efficient > > internal structure (e.g. using pointers instead of storing duplicate > > information) and translate the SNMP queries from/to the MIB structure. > > > > Of course the SNMP structure is not necessarily at all related to the > internal data structures. My understanding is that the reason for the > Rib-OUT table using RowPointer was the [not that well-founded, but still > widespread] concern about the amount of data returned in a full MIB walk. Speaking as a user of various MIBs while at a previous employer, I had way too many bugs open with too many vendors on mis-behaving large MIB walks. As a developer, while I realize that there shouldn't be this big of a concern over the problem space, it crops up way too many places for me to have stayed comfortable with the idea in the base BGP MIB v2. > (Also, it does concretely reduce the amount of data you need to process if > you're a management system that wants to know all of the RIB-IN plus > RIB-OUTs.) This ended up being a bigger reason for the change. The amount of redundant information consumed by management systems got to be very large, very quick. There was also the matter of consistency: When 200 peers all were recieving the same route, if your MIB walk is too slow it may change state prior to the completion of the walk. SNMP really is just the wrong tool for this sort of monitoring. > What about representing locally-advertised routes as being received from a > peer of type unknown, with zero length address? > > > > **** > > > > - Add support for BGP communities (as in your communities draft) > > in the NLRI in/out tables.**** > > > > There is no reason this can't be a future addition, right, in the interest > > of getting the base functionality out?**** > > > > ** ** > > > > [DC] Why should this simple addition hold back progress? > > > > It was removed in 2007 because of a lack of consensus about including it. > Is your sense that that lack of consensus has changed? An additional bit of conversation Bill and I had at IETF 84 while reviewing BGP MIBv2 issues was that nothing stops someone like you, Daniel, from adding an extension MIB that gives you the entire table, communities, etc. My suggestion, however, is that the representational issues around representing structured information in MIBs is that it's too much pain to really want to do. I would much more strongly support work to do this in YANG. (And if I ever manage to help get this MIB to RFC, might have some energy to help with that.) -- Jeff From jhaas@slice.pfrc.org Tue Sep 11 13:41:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51821F873C for ; Tue, 11 Sep 2012 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-6frTxiTa3M for ; Tue, 11 Sep 2012 13:41:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEB21F8731 for ; Tue, 11 Sep 2012 13:41:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AB927C3E5; Tue, 11 Sep 2012 16:41:42 -0400 (EDT) Date: Tue, 11 Sep 2012 16:41:42 -0400 From: Jeffrey Haas To: "Rajiv Asati (rajiva)" Message-ID: <20120911204142.GI8139@pfrc> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Robert Raszuk \(raszuk\)" , idr@ietf.org Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:41:44 -0000 On Tue, Aug 23, 2011 at 02:53:50PM -0500, Rajiv Asati (rajiva) wrote: > Done. -05 version just got posted. Nit: : 4. Conclusions : : : Both amendments discussed in section 2 provide further clarity and : granularity to help the BGP speaker to either continue to advertise You mean section 3 here. -- Jeff From petrlapu@microsoft.com Tue Sep 11 16:39:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31121E8054 for ; Tue, 11 Sep 2012 16:39:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51audEC-jjjW for ; Tue, 11 Sep 2012 16:39:30 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4F21E8051 for ; Tue, 11 Sep 2012 16:39:30 -0700 (PDT) Received: from mail101-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 23:39:29 +0000 Received: from mail101-co1 (localhost [127.0.0.1]) by mail101-co1-R.bigfish.com (Postfix) with ESMTP id EE97B3C00BC for ; Tue, 11 Sep 2012 23:39:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz4015Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail101-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=petrlapu@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail101-co1 (localhost.localdomain [127.0.0.1]) by mail101-co1 (MessageSwitch) id 1347406767763401_27487; Tue, 11 Sep 2012 23:39:27 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.247]) by mail101-co1.bigfish.com (Postfix) with ESMTP id AB97D580019 for ; Tue, 11 Sep 2012 23:39:27 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 23:39:20 +0000 Received: from TK5EX14MBXC299.redmond.corp.microsoft.com ([169.254.2.115]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Tue, 11 Sep 2012 23:39:20 +0000 From: Petr Lapukhov To: "idr@ietf.org" Thread-Topic: Feedback on "BGP Routing for Large Scale-Data Centers" Thread-Index: Ac2QdpLsblZACJxnSOGofZ3V79DFlg== Date: Tue, 11 Sep 2012 23:39:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [Idr] Feedback on "BGP Routing for Large Scale-Data Centers" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:39:31 -0000 Folks, We presented "BGP Routing for Large Scale Data-Centers" I-D to IDR at IETF8= 4 meeting, and submitted a more polished version of the document last month= at: http://www.ietf.org/id/draft-lapukhov-bgp-routing-large-dc-02.txt=20 Our intent is producing an informational document - be it individual submis= sion or WG document is not yet decided. If you have any suggestions/comment= s on the document we would love to hear them! Thanks, Petr Lapukhov Microsoft From Internet-Drafts@ietf.org Thu Sep 13 14:05:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721CA21F8611; Thu, 13 Sep 2012 14:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuJhGb5hPNWF; Thu, 13 Sep 2012 14:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1649F21F860D; Thu, 13 Sep 2012 14:05:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913210553.28931.16159.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 14:05:53 -0700 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-multisession-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:05:53 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multisession BGP Author(s) : J. Scudder, et al Filename : draft-ietf-idr-bgp-multisession Pages : 19 Date : Sept. 13, 2012 This specification augments "Multiprotocol Extensions for BGP-4" (MP- BGP) by proposing a mechanism to facilitate the use of multiple sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session-based attribute such as AFI/SAFI. This provides an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. Use of this approach is expected to provide finer-grained fault management and isolation as the BGP protocol is used to support more and more diverse services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-multisession"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-09-13140553.I-D@ietf.org> --NextPart-- From jie.dong@huawei.com Thu Sep 13 22:22:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C8221F8713 for ; Thu, 13 Sep 2012 22:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP+7uHnRaFaY for ; Thu, 13 Sep 2012 22:22:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65A21F86EF for ; Thu, 13 Sep 2012 22:22:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ73752; Fri, 14 Sep 2012 05:22:17 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:21:26 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:21:40 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 13:21:22 +0800 From: Jie Dong To: "idr@ietf.org" Thread-Topic: Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrA== Date: Fri, 14 Sep 2012 05:21:22 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273256CAA8szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:22:20 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273256CAA8szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Since the bgp-error-handling draft proposes to replace session-reset with t= reat-as-withdraw in some error cases, here I'd like to briefly compare thes= e two mechanisms. Basically, we could take session-reset as error-handling mechanism at sessi= on level, while treat-as-withdraw is error-handling at route level. Impacts: Session-reset impacts all the routes exchanged over the session, while trea= t-as-withdraw impacts only the routes carried in the malformed Update. Recovery: With session-reset, BGP speaker could recover the routes by re-establishing= the session, possibly with some back-off mechanism; while currently treat-= as-withdraw does not have corresponding recovery mechanism at route level. Diagnosing: With session-reset, the error codes/subcodes in Notification can be used fo= r diagnosing; with treat-as-withdraw, the error could be locally logged, bu= t Notification will not be sent. The mechanisms defined in operational-mess= age draft may be used to provide diagnosing info. Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C9273256CAA8szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Since the bgp-error-handling dr= aft proposes to replace session-reset with treat-as-withdraw in some error = cases, here I'd like to briefly compare these two mechanisms.

 

Basically, we could take sessio= n-reset as error-handling mechanism at session level, while treat-as-withdr= aw is error-handling at route level.

 

Impacts:

Session-reset impacts all the r= outes exchanged over the session, while treat-as-withdraw impacts only the = routes carried in the malformed Update.

 

Recovery:

With session-reset, BGP speaker= could recover the routes by re-establishing the session, possibly with som= e back-off mechanism; while currently treat-as-withdraw does not have corre= sponding recovery mechanism at route level.

 

Diagnosing:

With session-reset, the error c= odes/subcodes in Notification can be used for diagnosing; with treat-as-wit= hdraw, the error could be locally logged, but Notification will not be sent= . The mechanisms defined in operational-message draft may be used to provide diagnosing info.

 

 

Best regards,=

Jie

 

--_000_76CD132C3ADEF848BD84D028D243C9273256CAA8szxeml504mbschi_-- From enkechen@cisco.com Thu Sep 13 23:59:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29C21F84FC for ; Thu, 13 Sep 2012 23:59:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM6mmTmDRFPS for ; Thu, 13 Sep 2012 23:59:16 -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 738C421F843E for ; Thu, 13 Sep 2012 23:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7292; q=dns/txt; s=iport; t=1347605956; x=1348815556; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NL4jMBqokUYHSlKHlz/GWkuRxgHYF+QhkZuDZit6ykM=; b=UKD3yT0yWw1YhJfRu1+xtaisx7zTG6TWqMvr+CnvrXUCeceHk28OB4GM cTrVJ04ZidkmgNqraaKODFTbJbN3vTOa6MVjIWsqUCin434TZIfQlWpVq 8y6FHfxy/0pMZQbwBqtvGxUEp4BSE8jtlJmkQnc4mBYM5TkdAnYTo+BbE 8=; X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208,217";a="58143791" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 14 Sep 2012 06:59:16 +0000 Received: from sjc-vpn2-439.cisco.com (sjc-vpn2-439.cisco.com [10.21.113.183]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8E6xEeK022488; Fri, 14 Sep 2012 06:59:15 GMT Message-ID: <5052D5C6.7020309@cisco.com> Date: Thu, 13 Sep 2012 23:59:18 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jie Dong References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------040001090603080604040609" Cc: "idr@ietf.org" Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:59:17 -0000 This is a multi-part message in MIME format. --------------040001090603080604040609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jie, In terms of recovery, it has been shown that the session reset and reestablishment usually do not eliminate malformed updates. Instead the session would often get into the cycle of reset and reestablishment until the culprit route is removed from the routing system by the operator manually. -- Enke On 9/13/12 10:21 PM, Jie Dong wrote: > > Hi all, > > Since the bgp-error-handling draft proposes to replace session-reset > with treat-as-withdraw in some error cases, here I'd like to briefly > compare these two mechanisms. > > Basically, we could take session-reset as error-handling mechanism at > session level, while treat-as-withdraw is error-handling at route level. > > Impacts: > > Session-reset impacts all the routes exchanged over the session, while > treat-as-withdraw impacts only the routes carried in the malformed Update. > > Recovery: > > With session-reset, BGP speaker could recover the routes by > re-establishing the session, possibly with some back-off mechanism; > while currently treat-as-withdraw does not have corresponding recovery > mechanism at route level. > > Diagnosing: > > With session-reset, the error codes/subcodes in Notification can be > used for diagnosing; with treat-as-withdraw, the error could be > locally logged, but Notification will not be sent. The mechanisms > defined in operational-message draft may be used to provide diagnosing > info. > > Best regards, > > Jie > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------040001090603080604040609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jie,

In terms of recovery, it has been shown that the session reset and reestablishment usually do not eliminate malformed updates.  Instead the session would often get into the cycle of reset and reestablishment until the culprit route is removed from the routing system by the operator manually.

-- Enke

On 9/13/12 10:21 PM, Jie Dong wrote:

Hi all,

 

Since the bgp-error-handling draft proposes to replace session-reset with treat-as-withdraw in some error cases, here I'd like to briefly compare these two mechanisms.

 

Basically, we could take session-reset as error-handling mechanism at session level, while treat-as-withdraw is error-handling at route level.

 

Impacts:

Session-reset impacts all the routes exchanged over the session, while treat-as-withdraw impacts only the routes carried in the malformed Update.

 

Recovery:

With session-reset, BGP speaker could recover the routes by re-establishing the session, possibly with some back-off mechanism; while currently treat-as-withdraw does not have corresponding recovery mechanism at route level.

 

Diagnosing:

With session-reset, the error codes/subcodes in Notification can be used for diagnosing; with treat-as-withdraw, the error could be locally logged, but Notification will not be sent. The mechanisms defined in operational-message draft may be used to provide diagnosing info.

 

 

Best regards,

Jie

 



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------040001090603080604040609-- From jie.dong@huawei.com Fri Sep 14 02:52:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E786921F8505 for ; Fri, 14 Sep 2012 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwv1RF2EXUei for ; Fri, 14 Sep 2012 02:52:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1521F84F6 for ; Fri, 14 Sep 2012 02:52:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ94492; Fri, 14 Sep 2012 09:52:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 10:52:10 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 10:52:26 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 17:52:21 +0800 From: Jie Dong To: Enke Chen Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrP//lUIA//9VLVA= Date: Fri, 14 Sep 2012 09:52:20 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256CBE9@szxeml504-mbs.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> In-Reply-To: <5052D5C6.7020309@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273256CBE9szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:52:56 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273256CBE9szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Enke, Agree that in some cases session reset may not solve the problem. But in ma= ny field deployments when error occurs the session will be reset and re-est= ablished, usually with some back-off mechanism. If there is no session re-establishment after the session terminated, we ma= y lose the chance of recovering the session automatically in some error cas= es. The back-off mechanism can help in preventing frequent session re-estab= lishment. Best regards, Jie From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, September 14, 2012 2:59 PM To: Jie Dong Cc: idr@ietf.org; Enke Chen Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw Jie, In terms of recovery, it has been shown that the session reset and reestabl= ishment usually do not eliminate malformed updates. Instead the session wo= uld often get into the cycle of reset and reestablishment until the culprit= route is removed from the routing system by the operator manually. -- Enke On 9/13/12 10:21 PM, Jie Dong wrote: Hi all, Since the bgp-error-handling draft proposes to replace session-reset with t= reat-as-withdraw in some error cases, here I'd like to briefly compare thes= e two mechanisms. Basically, we could take session-reset as error-handling mechanism at sessi= on level, while treat-as-withdraw is error-handling at route level. Impacts: Session-reset impacts all the routes exchanged over the session, while trea= t-as-withdraw impacts only the routes carried in the malformed Update. Recovery: With session-reset, BGP speaker could recover the routes by re-establishing= the session, possibly with some back-off mechanism; while currently treat-= as-withdraw does not have corresponding recovery mechanism at route level. Diagnosing: With session-reset, the error codes/subcodes in Notification can be used fo= r diagnosing; with treat-as-withdraw, the error could be locally logged, bu= t Notification will not be sent. The mechanisms defined in operational-mess= age draft may be used to provide diagnosing info. Best regards, Jie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_76CD132C3ADEF848BD84D028D243C9273256CBE9szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Enke= ,

&n= bsp;

Agree t= hat in some cases session reset may not solve the problem. But in many fiel= d deployments when error occurs the session will be reset and re-establishe= d, usually with some back-off mechanism.

&n= bsp;

If ther= e is no session re-establishment after the session terminated, we may lose = the chance of recovering the session automatically in some error cases. The= back-off mechanism can help in preventing frequent session re-establishment.

&n= bsp;

Best re= gards,

Jie

&n= bsp;

From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Friday, September 14, 2012 2:59 PM
To: Jie Dong
Cc: idr@ietf.org; Enke Chen
Subject: Re: [Idr] Comparison between session-reset and treat-as-wit= hdraw

 

Jie,

In terms of recovery, it has been shown that the session reset and reestabl= ishment usually do not eliminate malformed updates.  Instead the sessi= on would often get into the cycle of reset and reestablishment until the cu= lprit route is removed from the routing system by the operator manually.

-- Enke

On 9/13/12 10:21 PM, Jie Dong wrote:

Hi all,

 

Since the bgp-error-handling dr= aft proposes to replace session-reset with treat-as-withdraw in some error = cases, here I'd like to briefly compare these two mechanisms.

 

Basically, we could take sessio= n-reset as error-handling mechanism at session level, while treat-as-withdr= aw is error-handling at route level.

 

Impacts:

Session-reset impacts all the r= outes exchanged over the session, while treat-as-withdraw impacts only the = routes carried in the malformed Update.

 

Recovery:

With session-reset, BGP speaker= could recover the routes by re-establishing the session, possibly with som= e back-off mechanism; while currently treat-as-withdraw does not have corre= sponding recovery mechanism at route level.

 

Diagnosing:

With session-reset, the error c= odes/subcodes in Notification can be used for diagnosing; with treat-as-wit= hdraw, the error could be locally logged, but Notification will not be sent= . The mechanisms defined in operational-message draft may be used to provide diagnosing info.

 

 

Best regards,=

Jie

 




_______________________________________________
Idr mailing list
Idr@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/idr

 

--_000_76CD132C3ADEF848BD84D028D243C9273256CBE9szxeml504mbschi_-- From randy@psg.com Fri Sep 14 04:15:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5B621F8518 for ; Fri, 14 Sep 2012 04:15:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg8+cIux5UWh for ; Fri, 14 Sep 2012 04:15:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 13BF521F849B for ; Fri, 14 Sep 2012 04:15:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TCTry-000Nih-Ba; Fri, 14 Sep 2012 11:15:34 +0000 Date: Fri, 14 Sep 2012 20:15:33 +0900 Message-ID: From: Randy Bush To: Enke Chen In-Reply-To: <5052D5C6.7020309@cisco.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 11:15:36 -0000 > In terms of recovery, it has been shown that the session reset and > reestablishment usually do not eliminate malformed updates. Instead > the session would often get into the cycle of reset and > reestablishment until the culprit route is removed from the routing > system by the operator manually. been there. have coffee cup and tee shirt. sadly sessions go bouncy bouncy is not uncommon. pathological extreme example, earlier this week i watched someone else have to rboot their very large router to get a stuck route out. randy From john@jlc.net Fri Sep 14 08:00:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4F421F853B for ; Fri, 14 Sep 2012 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.171 X-Spam-Level: X-Spam-Status: No, score=-106.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m5VA4jn-M7o for ; Fri, 14 Sep 2012 08:00:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7EED621F853A for ; Fri, 14 Sep 2012 08:00:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DE0E533C23; Fri, 14 Sep 2012 11:00:14 -0400 (EDT) Date: Fri, 14 Sep 2012 11:00:14 -0400 From: John Leslie To: Randy Bush Message-ID: <20120914150014.GI21618@verdi> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr wg Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:00:20 -0000 Randy Bush wrote: > [Enke Chen wrote:] > >> In terms of recovery, it has been shown that the session reset and >> reestablishment usually do not eliminate malformed updates. Instead >> the session would often get into the cycle of reset and >> reestablishment until the culprit route is removed from the routing >> system by the operator manually. > > been there. have coffee cup and tee shirt. sadly sessions go bouncy > bouncy is not uncommon. Yes... major pain, and very little information about the actual issue. But when the actual issue _is_ at the router getting the NOTIFICATION, we are "routing around the problem". We now are facing cases where the actual issue is elsewhere. Jie Dong wrote: ] ] If there is no session re-establishment after the session terminated, ] we may lose the chance of recovering the session automatically in ] some error cases. By which I guess he means that treat-as-withdraw has no automatic recovery path. And with that, I agree. We may succeed in "routing around the problem" when we use treat-as-withdraw; but I think we may lack any way to restore the original route when the actual issue is resolved. And that, IMHO, deserves some discussion... -- John Leslie From jie.dong@huawei.com Mon Sep 17 00:31:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFED21F8508 for ; Mon, 17 Sep 2012 00:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M7+fAePvZc9 for ; Mon, 17 Sep 2012 00:31:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9978221F84FC for ; Mon, 17 Sep 2012 00:31:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKS75615; Mon, 17 Sep 2012 07:31:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 08:30:12 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 08:30:35 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Mon, 17 Sep 2012 15:29:06 +0800 From: Jie Dong To: John Leslie , Randy Bush Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrP//lUIAgABHmYCAAD7GAP/7Rrzw Date: Mon, 17 Sep 2012 07:29:05 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> In-Reply-To: <20120914150014.GI21618@verdi> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 07:31:03 -0000 Hi John, > By which I guess he means that treat-as-withdraw has no automatic > recovery path. And with that, I agree. Yes, that's exactly what I mean. > We may succeed in "routing around the problem" when we use > treat-as-withdraw; but I think we may lack any way to restore the > original route when the actual issue is resolved. >=20 > And that, IMHO, deserves some discussion... Agreed, after using treat-as-withdraw on some routes, there will be some in= consistency between the sending and receiving BGP speaker for some time, an= d some user traffic may be affected. Thus similar to session reset, maybe t= he receiving speaker could try to recover the particular routes with some b= ack-off mechanism before manual intervention. Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Joh= n > Leslie > Sent: Friday, September 14, 2012 11:00 PM > To: Randy Bush > Cc: idr wg > Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw >=20 > Randy Bush wrote: > > [Enke Chen wrote:] > > > >> In terms of recovery, it has been shown that the session reset and > >> reestablishment usually do not eliminate malformed updates. Instead > >> the session would often get into the cycle of reset and > >> reestablishment until the culprit route is removed from the routing > >> system by the operator manually. > > > > been there. have coffee cup and tee shirt. sadly sessions go bouncy > > bouncy is not uncommon. >=20 > Yes... major pain, and very little information about the actual issue. >=20 > But when the actual issue _is_ at the router getting the NOTIFICATION, > we are "routing around the problem". >=20 > We now are facing cases where the actual issue is elsewhere. >=20 > Jie Dong wrote: > ] > ] If there is no session re-establishment after the session terminated, > ] we may lose the chance of recovering the session automatically in > ] some error cases. >=20 > By which I guess he means that treat-as-withdraw has no automatic > recovery path. And with that, I agree. >=20 > We may succeed in "routing around the problem" when we use > treat-as-withdraw; but I think we may lack any way to restore the > original route when the actual issue is resolved. >=20 > And that, IMHO, deserves some discussion... >=20 > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Mon Sep 17 00:39:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735DD21F849B for ; Mon, 17 Sep 2012 00:39:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En4YjflGvfSk for ; Mon, 17 Sep 2012 00:39:25 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B956921F8489 for ; Mon, 17 Sep 2012 00:39:24 -0700 (PDT) Received: (qmail 29274 invoked by uid 399); 17 Sep 2012 07:40:26 -0000 Received: from unknown (HELO ?192.168.6.80?) (pbs:robert@raszuk.net@64.134.239.181) by mail1310.opentransfer.com with ESMTPM; 17 Sep 2012 07:40:26 -0000 X-Originating-IP: 64.134.239.181 Message-ID: <5056D3A9.6080907@raszuk.net> Date: Mon, 17 Sep 2012 09:39:21 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jie Dong References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr wg , John Leslie Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 07:39:25 -0000 All, Treat-as-withdraw was supposed to be used with bgp-operational-message. Using is as default before bgp-operational-message is available is IMHO a mistake. Regards, R. > Hi John, > >> By which I guess he means that treat-as-withdraw has no automatic >> recovery path. And with that, I agree. > > Yes, that's exactly what I mean. > >> We may succeed in "routing around the problem" when we use >> treat-as-withdraw; but I think we may lack any way to restore the >> original route when the actual issue is resolved. >> >> And that, IMHO, deserves some discussion... > > Agreed, after using treat-as-withdraw on some routes, there will be some inconsistency between the sending and receiving BGP speaker for some time, and some user traffic may be affected. Thus similar to session reset, maybe the receiving speaker could try to recover the particular routes with some back-off mechanism before manual intervention. > > > Best regards, > Jie From iesg-secretary@ietf.org Mon Sep 17 12:04:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981A021E8037; Mon, 17 Sep 2012 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBdpkpeel4eu; Mon, 17 Sep 2012 12:04:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68021E8045; Mon, 17 Sep 2012 12:04:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917190446.14380.59616.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:04:46 -0700 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Codification of AS 0 processing.' to Proposed Standard (draft-ietf-idr-as0-06.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:04:47 -0000 The IESG has approved the following document: - 'Codification of AS 0 processing.' (draft-ietf-idr-as0-06.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-as0/ Technical Summary This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN and AS_PATH / AS4_PATH BGP attribute. This is important since although it has long been understood that zero is not a valid AS number, this restriction has never been formally specified. Working Group Summary There was active discussion in the WG and the document passed through a number of iterations reflecting that. In the end the document although short reflects a surprising amount of tuning. Document Quality There are at least two known BGP implementations that do not accept AS number 0 in an AS_PATH as specified in the draft. (Indeed, this appears to have been accepted implementation practice prior to the draft's publication.) Personnel John Scudder is the Document Shepherd. Stewart Bryant is the Responsible Area Director. RFC Editor Note OLD: 3. IANA Considerations The IANA is requested to update the Reference for number 0 in the "Autonomous System (AS) Numbers" registry to reference this document. NEW: 3. IANA Considerations The IANA is requested to update the registry for 16-bit Autonomous System Numbers so that the entry for AS 0 is simply Reserved. END From rajiva@cisco.com Mon Sep 17 13:12:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B077621E804A for ; Mon, 17 Sep 2012 13:12:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfED2jk+QAfM for ; Mon, 17 Sep 2012 13:12:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5421E8048 for ; Mon, 17 Sep 2012 13:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=870; q=dns/txt; s=iport; t=1347912720; x=1349122320; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jiXHY7QZsW1DtZIfDswVui1F7GJ3xRDN1UHYfdTSoCY=; b=INBfVgtKlgy9PDjML3J5eOaBEAFrO4Afh3JAeFeUUSiIqmKW918W7cEg lWFFQsAM4phGB1emPYzJ6R7YnvBy8fVam8+U2sBB1GQjxaHBWEes7ZTT3 UH/Amk+vZln84pjkStPP36VqNJt66/EqnrgxXXrsCAP4n1HKLV3esO5os s=; X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="122479730" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 17 Sep 2012 20:12:00 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HKBx2Y027122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 20:11:59 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 15:11:59 -0500 From: "Rajiv Asati (rajiva)" To: Jeffrey Haas Thread-Topic: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AQHNkF3bS4R0+tJICk+IzRajqVtbIpePEWWA Date: Mon, 17 Sep 2012 20:11:59 +0000 Message-ID: In-Reply-To: <20120911204142.GI8139@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.237.12] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--31.007800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <28EF96D2CB8B0E46A70A9B53B12A3E7B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Robert Raszuk \(raszuk\)" , "idr@ietf.org" Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:12:00 -0000 Sure, will fix it (though I have not kept track of what was done after the WGLC).=20 Thanks, Jeff. Cheers, Rajiv PS: Wow..you are checking emails from an yr ago? :) -----Original Message----- From: Jeffrey Haas Date: Tuesday, September 11, 2012 4:41 PM To: Rajiv Asati Cc: John Scudder , "Robert Raszuk (raszuk)" , "idr@ietf.org" Subject: Re: [Idr]=20 I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt >On Tue, Aug 23, 2011 at 02:53:50PM -0500, Rajiv Asati (rajiva) wrote: >> Done. -05 version just got posted. > >Nit: >: 4. Conclusions >:=20 >:=20 >: Both amendments discussed in section 2 provide further clarity and >: granularity to help the BGP speaker to either continue to advertise > >You mean section 3 here. > >-- Jeff From jie.dong@huawei.com Mon Sep 17 23:49:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867F21E80A7 for ; Mon, 17 Sep 2012 23:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtu20OD7ZxUB for ; Mon, 17 Sep 2012 23:49:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC421E8064 for ; Mon, 17 Sep 2012 23:49:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKT69237; Tue, 18 Sep 2012 06:49:49 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 07:49:21 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 14:49:47 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 14:49:41 +0800 From: Jie Dong To: Robert Raszuk Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrP//lUIAgABHmYCAAD7GAP/7RrzwgAj0a4D//ffiIA== Date: Tue, 18 Sep 2012 06:49:39 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg , John Leslie Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 06:49:51 -0000 Hi Robert, Agree that bgp-operational-message could provide detailed diagnostic inform= ation which would be quite helpful for diagnosing of treat-as-withdraw even= ts. And some mechanism for automatic route recovery can also be helpful aft= er some important routes are treat-as-withdraw. Regards, Jie > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, September 17, 2012 3:37 PM > To: Jie Dong > Cc: John Leslie; Randy Bush; idr wg > Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw >=20 > All, >=20 > Treat-as-withdraw was supposed to be used with > bgp-operational-message. Using is as default before > bgp-operational-message is available is IMHO a mistake. >=20 > Regards, > R. >=20 > On Mon, Sep 17, 2012 at 9:29 AM, Jie Dong wrote: > > Hi John, > > > >> By which I guess he means that treat-as-withdraw has no automatic > >> recovery path. And with that, I agree. > > > > Yes, that's exactly what I mean. > > > >> We may succeed in "routing around the problem" when we use > >> treat-as-withdraw; but I think we may lack any way to restore the > >> original route when the actual issue is resolved. > >> > >> And that, IMHO, deserves some discussion... > > > > Agreed, after using treat-as-withdraw on some routes, there will be som= e > inconsistency between the sending and receiving BGP speaker for some time= , > and some user traffic may be affected. Thus similar to session reset, may= be the > receiving speaker could try to recover the particular routes with some ba= ck-off > mechanism before manual intervention. > > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > John > >> Leslie > >> Sent: Friday, September 14, 2012 11:00 PM > >> To: Randy Bush > >> Cc: idr wg > >> Subject: Re: [Idr] Comparison between session-reset and treat-as-withd= raw > >> > >> Randy Bush wrote: > >> > [Enke Chen wrote:] > >> > > >> >> In terms of recovery, it has been shown that the session reset and > >> >> reestablishment usually do not eliminate malformed updates. Instea= d > >> >> the session would often get into the cycle of reset and > >> >> reestablishment until the culprit route is removed from the routing > >> >> system by the operator manually. > >> > > >> > been there. have coffee cup and tee shirt. sadly sessions go bounc= y > >> > bouncy is not uncommon. > >> > >> Yes... major pain, and very little information about the actual iss= ue. > >> > >> But when the actual issue _is_ at the router getting the NOTIFICATI= ON, > >> we are "routing around the problem". > >> > >> We now are facing cases where the actual issue is elsewhere. > >> > >> Jie Dong wrote: > >> ] > >> ] If there is no session re-establishment after the session terminated= , > >> ] we may lose the chance of recovering the session automatically in > >> ] some error cases. > >> > >> By which I guess he means that treat-as-withdraw has no automatic > >> recovery path. And with that, I agree. > >> > >> We may succeed in "routing around the problem" when we use > >> treat-as-withdraw; but I think we may lack any way to restore the > >> original route when the actual issue is resolved. > >> > >> And that, IMHO, deserves some discussion... > >> > >> -- > >> John Leslie > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Tue Sep 18 00:52:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D75621F847A for ; Tue, 18 Sep 2012 00:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-NtOmtG8qvQ for ; Tue, 18 Sep 2012 00:52:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFA21F8476 for ; Tue, 18 Sep 2012 00:52:50 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8EBD72DC2AC; Tue, 18 Sep 2012 09:52:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 56D5E27C05B; Tue, 18 Sep 2012 09:52:49 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 09:52:48 +0200 From: To: "robert@raszuk.net" , Jie Dong Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: AQHNlKeVCORrcpfB30iLOUYDng+ZQJePtCNQ Date: Tue, 18 Sep 2012 07:52:48 +0000 Message-ID: <29193_1347954769_50582851_29193_2287_1_53C29892C857584299CBF5D05346208A0CD89B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> <5056D3A9.6080907@raszuk.net> In-Reply-To: <5056D3A9.6080907@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.18.72416 Cc: idr wg , John Leslie Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 07:52:52 -0000 Hi Robert, all >From: Robert Raszuk >Sent: Monday, September 17, 2012 9:39 AM > >All, > >Treat-as-withdraw was supposed to be used with bgp-operational-message. >Using is as default before bgp-operational-message is available is IMHO >a mistake. I think I see what you mean and I agree that this could make sense from a t= heoretical point of view. However, from a roadmap / network management POV, IMHO, bgp-error-handling = is more important/urgent that bgp-operational-message. Also, I would distinguish the iBGP and eBGP cases: - for iBGP, the lack of bgp-operational-message is less of an issue as ther= e are (should be) other existing means to know about the problem. Also IMO = bgp-error-handling is crucial on iBGP as we can't afford to have a single e= rror shutting down both redundant iBGP sessions. Moreover, possibly on 10s = of PE at the same time. Especially in the absence of a "persistence" safety= net. - for eBGP, bgp-operational-message is indeed of importance, but whatever t= he order of feature delivery, deploying a local feature (bgp-error-handling= ) will always be easier and hence faster than a feature requiring interoper= ability. Especially between ASes. (cf GR vs NSR on eBGP PE-CE sessions). Bottom line: IMO bgp-error-handling should not wait (and hence have require= d dependency) for bgp-operational-message. Regards, Bruno >Regards, >R. > >> Hi John, >> >>> By which I guess he means that treat-as-withdraw has no automatic >>> recovery path. And with that, I agree. >> >> Yes, that's exactly what I mean. >> >>> We may succeed in "routing around the problem" when we use >>> treat-as-withdraw; but I think we may lack any way to restore the >>> original route when the actual issue is resolved. >>> >>> And that, IMHO, deserves some discussion... >> >> Agreed, after using treat-as-withdraw on some routes, there will be some >inconsistency between the sending and receiving BGP speaker for some time,= and >some user traffic may be affected. Thus similar to session reset, maybe the >receiving speaker could try to recover the particular routes with some bac= k-off >mechanism before manual intervention. >> >> >> Best regards, >> Jie > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From internet-drafts@ietf.org Wed Sep 19 13:05:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC921E80B2; Wed, 19 Sep 2012 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHU5-YiSXzgB; Wed, 19 Sep 2012 13:05:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33AB21E80AE; Wed, 19 Sep 2012 13:05:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919200534.5051.46191.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 13:05:34 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 20:05:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : North-Bound Distribution of Link-State and TE Informatio= n using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Filename : draft-ietf-idr-ls-distribution-00.txt Pages : 28 Date : 2012-09-19 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohan.nanduri@gmail.com Thu Sep 20 12:41:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A321F8683 for ; Thu, 20 Sep 2012 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKIfyXR8Czbc for ; Thu, 20 Sep 2012 12:41:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 470AC21F867C for ; Thu, 20 Sep 2012 12:41:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2825504obb.31 for ; Thu, 20 Sep 2012 12:41:32 -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=zog1hNPvssYv9IGkaawmrfMyxUsixH6XqF4X1Iv055A=; b=xt0SCmDF1o719qwzGvA+JQ3+dfdgjuksqDWEfENYYCcjK+lRm5UQjpSfFb3iOdfqsY b8EQDzRALaSNTDGthb/axvRBcZbqSSk2PI7RnVqlwRBguPFpBpU/AW87CjD9Grdz+g4k qjf3KHCmJJFXfBDySbzmv+QQHNtxZ4rUYB7kc7fsJlsicVIDImTu0Djs25beomtJ54Wu JgAhu4/S5tWC99yMnBIHIFZGM0EOQoOpaFkD2mB2G17ymg6jCNjrIUJZRwwfS9Al85yb C+h0Y+o6upqsmzSXxvXHWiFGY4CusiM7BIk4e3oEKoQ+8v6oUoVnKrGHbVAey7FiwNAx eDqw== MIME-Version: 1.0 Received: by 10.60.13.37 with SMTP id e5mr2115151oec.98.1348170092678; Thu, 20 Sep 2012 12:41:32 -0700 (PDT) Received: by 10.182.35.193 with HTTP; Thu, 20 Sep 2012 12:41:32 -0700 (PDT) In-Reply-To: <20120911192958.GD8139@pfrc> References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> <20120911192958.GD8139@pfrc> Date: Thu, 20 Sep 2012 15:41:32 -0400 Message-ID: From: Mohan Nanduri To: Susan Hares , idr@ietf.org, "Jon Mitchell (GNS)" , "John G. Scudder" Content-Type: multipart/alternative; boundary=e89a8fb1f35078900504ca274fe2 Subject: Re: [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:41:35 -0000 --e89a8fb1f35078900504ca274fe2 Content-Type: text/plain; charset=ISO-8859-1 Support adoption of this draft as a working group document. Cheers, -Mohan On Tue, Sep 11, 2012 at 3:29 PM, Jeffrey Haas wrote: > On Mon, Aug 20, 2012 at 10:43:09AM -0400, Susan Hares wrote: > > IDR WG: > > This is call for adoption of > > draft-mitchell-idr-private-as-reservation-01 > > as a working group draft, > > I support adoption of this draft as a working group document. > > I also believe the text in -01 has reached a level of maturity that once > the > "why would anyone want more private AS numbers" discussion has reached > whatever conclusion it may that it is ready for last call. > > The one minor detail I'd like to see resolved is how IANA will choose to > interpret AS 65535 based on this current draft. > > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --e89a8fb1f35078900504ca274fe2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support adoption of this draft as a working group document.
= =A0
Cheers,
-Mohan
=A0
=A0


=A0
On Tue, Sep 11, 2012 at 3:29 = PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Mon, Aug 20, 2012 at 10:43:09AM -0400, Susan Hares wrot= e:
> IDR WG:
> This is call for adoption of
> draft-mitchell-idr-private-as-reservation-01
> as a working group draft,

I support adoption of this draft as a working group document.

I also believe the text in -01 has reached a level of maturity that once th= e
"why would anyone want more private AS numbers" discussion has re= ached
whatever conclusion it may that it is ready for last call.

The one minor detail I'd like to see resolved is how IANA will choose t= o
interpret AS 65535 based on this current draft.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8fb1f35078900504ca274fe2-- From shares@ndzh.com Thu Sep 20 15:58:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8457421E8034 for ; Thu, 20 Sep 2012 15:58:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiWOvQOzMPgN for ; Thu, 20 Sep 2012 15:58:32 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id B48FD21E803C for ; Thu, 20 Sep 2012 15:58:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=222.128.198.2; Received: from SKH2012HPLT (unverified [222.128.198.2]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3629251-1945496 for multiple; Thu, 20 Sep 2012 18:58:21 -0400 From: "Susan Hares" To: "'Jie Dong'" , "'Robert Raszuk'" References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> Date: Thu, 20 Sep 2012 18:58:18 -0400 Message-ID: <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFbY76+B0Wis2gY2Z5FB2oPrqwVawGY7l1lAWU8kXwCqlEUWwIEam2LAk/welUCHxP995gXX8DA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , 'John Leslie' Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:58:33 -0000 Robert and Jie: Could you both review exactly what information you feel is useful to put in the bgp-operational-message for the treat-as-withdrawl case? Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie Dong Sent: Tuesday, September 18, 2012 2:50 AM To: Robert Raszuk Cc: idr wg; John Leslie Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw Hi Robert, Agree that bgp-operational-message could provide detailed diagnostic information which would be quite helpful for diagnosing of treat-as-withdraw events. And some mechanism for automatic route recovery can also be helpful after some important routes are treat-as-withdraw. Regards, Jie > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, September 17, 2012 3:37 PM > To: Jie Dong > Cc: John Leslie; Randy Bush; idr wg > Subject: Re: [Idr] Comparison between session-reset and > treat-as-withdraw > > All, > > Treat-as-withdraw was supposed to be used with > bgp-operational-message. Using is as default before > bgp-operational-message is available is IMHO a mistake. > > Regards, > R. > > On Mon, Sep 17, 2012 at 9:29 AM, Jie Dong wrote: > > Hi John, > > > >> By which I guess he means that treat-as-withdraw has no > >> automatic recovery path. And with that, I agree. > > > > Yes, that's exactly what I mean. > > > >> We may succeed in "routing around the problem" when we use > >> treat-as-withdraw; but I think we may lack any way to restore the > >> original route when the actual issue is resolved. > >> > >> And that, IMHO, deserves some discussion... > > > > Agreed, after using treat-as-withdraw on some routes, there will be > > some > inconsistency between the sending and receiving BGP speaker for some > time, and some user traffic may be affected. Thus similar to session > reset, maybe the receiving speaker could try to recover the particular > routes with some back-off mechanism before manual intervention. > > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > >> Of > John > >> Leslie > >> Sent: Friday, September 14, 2012 11:00 PM > >> To: Randy Bush > >> Cc: idr wg > >> Subject: Re: [Idr] Comparison between session-reset and > >> treat-as-withdraw > >> > >> Randy Bush wrote: > >> > [Enke Chen wrote:] > >> > > >> >> In terms of recovery, it has been shown that the session reset > >> >> and reestablishment usually do not eliminate malformed updates. > >> >> Instead the session would often get into the cycle of reset and > >> >> reestablishment until the culprit route is removed from the > >> >> routing system by the operator manually. > >> > > >> > been there. have coffee cup and tee shirt. sadly sessions go > >> > bouncy bouncy is not uncommon. > >> > >> Yes... major pain, and very little information about the actual issue. > >> > >> But when the actual issue _is_ at the router getting the > >> NOTIFICATION, we are "routing around the problem". > >> > >> We now are facing cases where the actual issue is elsewhere. > >> > >> Jie Dong wrote: > >> ] > >> ] If there is no session re-establishment after the session > >> terminated, ] we may lose the chance of recovering the session > >> automatically in ] some error cases. > >> > >> By which I guess he means that treat-as-withdraw has no > >> automatic recovery path. And with that, I agree. > >> > >> We may succeed in "routing around the problem" when we use > >> treat-as-withdraw; but I think we may lack any way to restore the > >> original route when the actual issue is resolved. > >> > >> And that, IMHO, deserves some discussion... > >> > >> -- > >> John Leslie > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Thu Sep 20 16:39:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2312721E8034 for ; Thu, 20 Sep 2012 16:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKNW4Ncdjr0w for ; Thu, 20 Sep 2012 16:39:46 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 60D9811E8099 for ; Thu, 20 Sep 2012 16:39:46 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUFupQhmhM+Cu8+qQrHmvuzZVs1mlyxHJ@postini.com; Thu, 20 Sep 2012 16:39:46 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 16:38:17 -0700 Received: from [172.16.13.202] ([172.16.13.202]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q8KNcGh59187 for ; Thu, 20 Sep 2012 16:38:16 -0700 (PDT) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Sep 2012 19:38:15 -0400 References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> To: "idr@ietf.org List" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:39:47 -0000 Folks, FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This draft, = assuming it progresses, represents a significant update to the BGP = protocol, notably in terms of AS_PATH handling. If you haven't looked at = it already, please consider taking the time to do so.=20 Comments should go to both the sidr@ietf.org and idr@ietf.org mailing = lists. There has already been some discussion of the draft on the sidr mailing = list. Archives are here = http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html --John P.S.: If you intend to review it but need more time, please speak up, = and say how much more time you will need. Begin forwarded message: > From: "Murphy, Sandra" > Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 > Date: September 15, 2012 7:45:13 AM EDT > To: "sidr@ietf.org" >=20 > This starts a working group last call for = draft-ietf-sidr-bgpsec-protocol-05. The draft is available at = http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and = https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >=20 > Please review this draft to see if you think it is ready for = publication. Send end comments to the list. =20 >=20 > The WGLC will end on 29 September 2012. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robert@raszuk.net Thu Sep 20 21:58:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811DA21F84F6 for ; Thu, 20 Sep 2012 21:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LNOnSt00kC4 for ; Thu, 20 Sep 2012 21:58:14 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7127B21F8470 for ; Thu, 20 Sep 2012 21:58:13 -0700 (PDT) Received: (qmail 14462 invoked by uid 399); 21 Sep 2012 04:59:16 -0000 Received: from unknown (HELO ?192.168.6.80?) (pbs:robert@raszuk.net@64.134.239.181) by mail1310.opentransfer.com with ESMTPM; 21 Sep 2012 04:59:16 -0000 X-Originating-IP: 64.134.239.181 Message-ID: <505BF3E1.6030109@raszuk.net> Date: Fri, 21 Sep 2012 06:58:09 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Susan Hares References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> In-Reply-To: <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'John Leslie' , 'idr wg' Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 04:58:15 -0000 Hi Sue, As I am sure you remember that operational message in the current form of IDR WG document is a merge of advisory-message and diagnostic-message drafts proposed for adoption. We have spent significant amount of time between Dave, Rob, Enke and myself to make sure it is sufficiently reach to be helpful in most BGP deployment cases today which does include error cases. As you can see section "3.4.3. DUMP TLVs" contains the essence of what needs to be reported to the peer at the event of "treat-as-withdraw" accident. Ref: http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 In the light of the above we are very welcome to get more input from IDR WG if what we have currently in the bgp-operational-message is good enough or that it perhaps would benefit from addition of XYZ ... We will be happy to consider any input. Other then that while Jie may his point of view I personally do not have additional comments to the draft. Best regards, R. > Robert and Jie: > > Could you both review exactly what information you feel is useful to put in > the bgp-operational-message for the treat-as-withdraw case? > > Sue > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie > Dong > Sent: Tuesday, September 18, 2012 2:50 AM > To: Robert Raszuk > Cc: idr wg; John Leslie > Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw > > Hi Robert, > > Agree that bgp-operational-message could provide detailed diagnostic > information which would be quite helpful for diagnosing of treat-as-withdraw > events. And some mechanism for automatic route recovery can also be helpful > after some important routes are treat-as-withdraw. > > Regards, > Jie > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Monday, September 17, 2012 3:37 PM >> To: Jie Dong >> Cc: John Leslie; Randy Bush; idr wg >> Subject: Re: [Idr] Comparison between session-reset and >> treat-as-withdraw >> >> All, >> >> Treat-as-withdraw was supposed to be used with >> bgp-operational-message. Using is as default before >> bgp-operational-message is available is IMHO a mistake. >> >> Regards, >> R. From robert@raszuk.net Thu Sep 20 22:59:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AFC21F861A for ; Thu, 20 Sep 2012 22:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7kwDcBDIPoz for ; Thu, 20 Sep 2012 22:59:07 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A795B21F8619 for ; Thu, 20 Sep 2012 22:59:07 -0700 (PDT) Received: (qmail 27807 invoked by uid 399); 21 Sep 2012 06:00:10 -0000 Received: from unknown (HELO ?192.168.6.80?) (pbs:robert@raszuk.net@64.134.239.181) by mail1310.opentransfer.com with ESMTPM; 21 Sep 2012 06:00:10 -0000 X-Originating-IP: 64.134.239.181 Message-ID: <505C0228.40805@raszuk.net> Date: Fri, 21 Sep 2012 07:59:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "John G. Scudder" References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 05:59:08 -0000 Hi John, The proposal of dropping AS_PATH and the intention to completely replace it with AS_SEC_PATH attribute has been negatively commented so many times in the past both on idr and sidr that by bringing just one thread below seems like erasing all other comments. The issues are not only related to routing .. they are also related to number of BGP monitoring stations deployed today which use AS_PATH attribute for real time BGP analysis. Do you expect all of those tools to change/be updated when IETF will publish path validation RFC ? To only bring few past comments: http://www.ietf.org/mail-archive/web/sidr/current/msg04693.html http://www.ietf.org/mail-archive/web/sidr/current/msg04695.html http://www.ietf.org/mail-archive/web/sidr/current/msg04701.html http://www.ietf.org/mail-archive/web/sidr/current/msg04721.html http://www.ietf.org/mail-archive/web/sidr/current/msg04722.html Regards, R. > Folks, > > FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This > draft, assuming it progresses, represents a significant update to the > BGP protocol, notably in terms of AS_PATH handling. If you haven't > looked at it already, please consider taking the time to do so. > > Comments should go to both the sidr@ietf.org and idr@ietf.org mailing > lists. > > There has already been some discussion of the draft on the sidr > mailing list. Archives are here > http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html > > --John > > P.S.: If you intend to review it but need more time, please speak up, > and say how much more time you will need. > > Begin forwarded message: > >> From: "Murphy, Sandra" Subject: [sidr] >> WGLC for draft-ietf-sidr-bgpsec-protocol-05 Date: September 15, >> 2012 7:45:13 AM EDT To: "sidr@ietf.org" >> >> This starts a working group last call for >> draft-ietf-sidr-bgpsec-protocol-05. The draft is available at >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and >> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >> >> Please review this draft to see if you think it is ready for >> publication. Send end comments to the list. >> >> The WGLC will end on 29 September 2012. >> >> --Sandy, speaking as wg co-chair >> _______________________________________________ sidr mailing list >> sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From jie.dong@huawei.com Thu Sep 20 23:05:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8120921E8037 for ; Thu, 20 Sep 2012 23:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXSYUim0V-xA for ; Thu, 20 Sep 2012 23:05:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A40211E809C for ; Thu, 20 Sep 2012 23:05:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX14569; Fri, 21 Sep 2012 06:05:25 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:04:46 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:05:21 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 14:05:17 +0800 From: Jie Dong To: Susan Hares , "'Robert Raszuk'" Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrP//lUIAgABHmYCAAD7GAP/7RrzwgAj0a4D//ffiIIAHwIYA//8HHjA= Date: Fri, 21 Sep 2012 06:05:16 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256EC24@szxeml504-mbs.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> In-Reply-To: <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'idr wg' , 'John Leslie' Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:05:29 -0000 Hi Sue and Robert,=20 IMO bgp-operational-message can provide diagnostic information to the sendi= ng speaker of the malformed updates, and currently I do not have additional= inputs to this draft.=20 My concern is since we already provide bgp session level recovery mechanism= for "session down" accident, accordingly do we also need recovery mechanis= m at route level for the new "route treat-as-withdraw" accident? Best regards, Jie > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Friday, September 21, 2012 6:58 AM > To: Jie Dong; 'Robert Raszuk' > Cc: 'idr wg'; 'John Leslie' > Subject: RE: [Idr] Comparison between session-reset and treat-as-withdraw >=20 > Robert and Jie: >=20 > Could you both review exactly what information you feel is useful to put = in > the bgp-operational-message for the treat-as-withdrawl case? >=20 > Sue >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie > Dong > Sent: Tuesday, September 18, 2012 2:50 AM > To: Robert Raszuk > Cc: idr wg; John Leslie > Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw >=20 > Hi Robert, >=20 > Agree that bgp-operational-message could provide detailed diagnostic > information which would be quite helpful for diagnosing of treat-as-withd= raw > events. And some mechanism for automatic route recovery can also be helpf= ul > after some important routes are treat-as-withdraw. >=20 > Regards, > Jie >=20 > > -----Original Message----- > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > > Raszuk > > Sent: Monday, September 17, 2012 3:37 PM > > To: Jie Dong > > Cc: John Leslie; Randy Bush; idr wg > > Subject: Re: [Idr] Comparison between session-reset and > > treat-as-withdraw > > > > All, > > > > Treat-as-withdraw was supposed to be used with > > bgp-operational-message. Using is as default before > > bgp-operational-message is available is IMHO a mistake. > > > > Regards, > > R. > > > > On Mon, Sep 17, 2012 at 9:29 AM, Jie Dong wrote: > > > Hi John, > > > > > >> By which I guess he means that treat-as-withdraw has no > > >> automatic recovery path. And with that, I agree. > > > > > > Yes, that's exactly what I mean. > > > > > >> We may succeed in "routing around the problem" when we use > > >> treat-as-withdraw; but I think we may lack any way to restore the > > >> original route when the actual issue is resolved. > > >> > > >> And that, IMHO, deserves some discussion... > > > > > > Agreed, after using treat-as-withdraw on some routes, there will be > > > some > > inconsistency between the sending and receiving BGP speaker for some > > time, and some user traffic may be affected. Thus similar to session > > reset, maybe the receiving speaker could try to recover the particular > > routes with some back-off mechanism before manual intervention. > > > > > > > > > Best regards, > > > Jie > > > > > >> -----Original Message----- > > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > > >> Of > > John > > >> Leslie > > >> Sent: Friday, September 14, 2012 11:00 PM > > >> To: Randy Bush > > >> Cc: idr wg > > >> Subject: Re: [Idr] Comparison between session-reset and > > >> treat-as-withdraw > > >> > > >> Randy Bush wrote: > > >> > [Enke Chen wrote:] > > >> > > > >> >> In terms of recovery, it has been shown that the session reset > > >> >> and reestablishment usually do not eliminate malformed updates. > > >> >> Instead the session would often get into the cycle of reset and > > >> >> reestablishment until the culprit route is removed from the > > >> >> routing system by the operator manually. > > >> > > > >> > been there. have coffee cup and tee shirt. sadly sessions go > > >> > bouncy bouncy is not uncommon. > > >> > > >> Yes... major pain, and very little information about the actual > issue. > > >> > > >> But when the actual issue _is_ at the router getting the > > >> NOTIFICATION, we are "routing around the problem". > > >> > > >> We now are facing cases where the actual issue is elsewhere. > > >> > > >> Jie Dong wrote: > > >> ] > > >> ] If there is no session re-establishment after the session > > >> terminated, ] we may lose the chance of recovering the session > > >> automatically in ] some error cases. > > >> > > >> By which I guess he means that treat-as-withdraw has no > > >> automatic recovery path. And with that, I agree. > > >> > > >> We may succeed in "routing around the problem" when we use > > >> treat-as-withdraw; but I think we may lack any way to restore the > > >> original route when the actual issue is resolved. > > >> > > >> And that, IMHO, deserves some discussion... > > >> > > >> -- > > >> John Leslie > > >> _______________________________________________ > > >> Idr mailing list > > >> Idr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From neil@domino.org Thu Sep 20 23:28:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1F21F8607 for ; Thu, 20 Sep 2012 23:28:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaVysfw7E3YA for ; Thu, 20 Sep 2012 23:28:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2F021F8566 for ; Thu, 20 Sep 2012 23:28:12 -0700 (PDT) Received: from mail251-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Sep 2012 06:28:11 +0000 Received: from mail251-va3 (localhost [127.0.0.1]) by mail251-va3-R.bigfish.com (Postfix) with ESMTP id 6BD2B92028D; Fri, 21 Sep 2012 06:28:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.133; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I1b0bI1432Id6f1izz1202h1d1ah1d2ahz31iz8275ch1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah1155h) Received-SPF: pass (mail251-va3: domain of domino.org designates 157.56.248.133 as permitted sender) client-ip=157.56.248.133; envelope-from=neil@domino.org; helo=AMXPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail251-va3 (localhost.localdomain [127.0.0.1]) by mail251-va3 (MessageSwitch) id 1348208889508513_1017; Fri, 21 Sep 2012 06:28:09 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.252]) by mail251-va3.bigfish.com (Postfix) with ESMTP id 6FD69104007A; Fri, 21 Sep 2012 06:28:09 +0000 (UTC) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Sep 2012 06:28:08 +0000 Received: from AMXPRD0310MB388.eurprd03.prod.outlook.com ([169.254.1.131]) by AMXPRD0310HT004.eurprd03.prod.outlook.com ([10.255.55.39]) with mapi id 14.16.0190.008; Fri, 21 Sep 2012 06:27:39 +0000 From: "Neil J. McRae" To: "" Thread-Topic: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr Thread-Index: AQHNl4k+1F5MLoJwxkCw/MjJJrFHFJeUTVYAgAAH/EI= Date: Fri, 21 Sep 2012 06:27:39 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> , <505C0228.40805@raszuk.net> In-Reply-To: <505C0228.40805@raszuk.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.40.253.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.248.133$juniper.net%12218%2%domino.org%True%True%0$ X-OriginatorOrg: domino.org Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:28:13 -0000 +1 not clear that this change is valuable I are no need to replace AS_PATH = at all. Sent from my iPhone On 21 Sep 2012, at 06:59, "Robert Raszuk" wrote: > Hi John, >=20 > The proposal of dropping AS_PATH and the intention to completely replace = it with AS_SEC_PATH attribute has been negatively commented so many times i= n the past both on idr and sidr that by bringing just one thread below seem= s like erasing all other comments. >=20 > The issues are not only related to routing .. they are also related to nu= mber of BGP monitoring stations deployed today which use AS_PATH attribute = for real time BGP analysis. Do you expect all of those tools to change/be u= pdated when IETF will publish path validation RFC ? >=20 > To only bring few past comments: >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg04693.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04695.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04701.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04721.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04722.html >=20 > Regards, > R. >=20 >> Folks, >>=20 >> FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This >> draft, assuming it progresses, represents a significant update to the >> BGP protocol, notably in terms of AS_PATH handling. If you haven't >> looked at it already, please consider taking the time to do so. >>=20 >> Comments should go to both the sidr@ietf.org and idr@ietf.org mailing >> lists. >>=20 >> There has already been some discussion of the draft on the sidr >> mailing list. Archives are here >> http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html >>=20 >> --John >>=20 >> P.S.: If you intend to review it but need more time, please speak up, >> and say how much more time you will need. >>=20 >> Begin forwarded message: >>=20 >>> From: "Murphy, Sandra" Subject: [sidr] >>> WGLC for draft-ietf-sidr-bgpsec-protocol-05 Date: September 15, >>> 2012 7:45:13 AM EDT To: "sidr@ietf.org" >>>=20 >>> This starts a working group last call for >>> draft-ietf-sidr-bgpsec-protocol-05. The draft is available at >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>>=20 >>> Please review this draft to see if you think it is ready for >>> publication. Send end comments to the list. >>>=20 >>> The WGLC will end on 29 September 2012. >>>=20 >>> --Sandy, speaking as wg co-chair >>> _______________________________________________ sidr mailing list >>> sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From jie.dong@huawei.com Thu Sep 20 23:58:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F54721F869E for ; Thu, 20 Sep 2012 23:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP66Xvs41iwq for ; Thu, 20 Sep 2012 23:58:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEA821F869F for ; Thu, 20 Sep 2012 23:58:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW54051; Fri, 21 Sep 2012 06:58:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 07:58:03 +0100 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 14:58:30 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 14:58:26 +0800 From: Jie Dong To: Robert Raszuk Thread-Topic: [Idr] Comparison between session-reset and treat-as-withdraw Thread-Index: Ac2SOMXpX+oBbafARBG7DO6Hm7ulrP//lUIAgABHmYCAAD7GAP/7RrzwgAj0a4D//ffiIIAHwIYA//8HHjAALk4BgP//c9LA Date: Fri, 21 Sep 2012 06:58:25 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256EC95@szxeml504-mbs.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273256CAA8@szxeml504-mbs.china.huawei.com> <5052D5C6.7020309@cisco.com> <20120914150014.GI21618@verdi> <76CD132C3ADEF848BD84D028D243C9273256D527@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256DB26@szxeml504-mbs.china.huawei.com> <00bb01cd9783$6ec47090$4c4d51b0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C9273256EC24@szxeml504-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg , John Leslie , Susan Hares Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:58:56 -0000 Hi Robert,=20 I agree that the DUMP message should trigger the same error notification pr= iority as session reset to the operators for diagnosing. OTOH, Today's session reset also includes session re-establishment and re-a= dvertisement of all the routes over the session, this is what I called "ses= sion level recovery". While we know that not all the errors can be solved w= ith session re-establishment and route re-advertisement, usually such mecha= nism is deployed in networks, with some back-off mechanism. This is somewha= t similar to restarting my cell phone when there is something wrong with it= , before referring to the after-sale engineer. Thus I would like to know if we need some equivalent for "treat-as-withdraw= " Regards, Jie > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, September 21, 2012 2:13 PM > To: Jie Dong > Cc: Susan Hares; idr wg; John Leslie > Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw >=20 > Hi Jie, >=20 > I understand your comment and concern. From the point of view of > bgp-operational message point of view the DUMP message triggered by > "treat-as-withdraw" should be treated with equal error level handling > priority as today session reset. >=20 > The root cause for trigger of "treat-as-withdraw" IMHO can not be > determined programatically today. So we do need operator's > intervention on both ends to diagnose the real issue and at least try > to fix it. >=20 > Rgs, > R, >=20 > On Fri, Sep 21, 2012 at 8:05 AM, Jie Dong wrote: > > Hi Sue and Robert, > > > > IMO bgp-operational-message can provide diagnostic information to the > sending speaker of the malformed updates, and currently I do not have > additional inputs to this draft. > > > > My concern is since we already provide bgp session level recovery mecha= nism > for "session down" accident, accordingly do we also need recovery mechani= sm > at route level for the new "route treat-as-withdraw" accident? > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Susan Hares [mailto:shares@ndzh.com] > >> Sent: Friday, September 21, 2012 6:58 AM > >> To: Jie Dong; 'Robert Raszuk' > >> Cc: 'idr wg'; 'John Leslie' > >> Subject: RE: [Idr] Comparison between session-reset and treat-as-withd= raw > >> > >> Robert and Jie: > >> > >> Could you both review exactly what information you feel is useful to p= ut in > >> the bgp-operational-message for the treat-as-withdrawl case? > >> > >> Sue > >> > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jie > >> Dong > >> Sent: Tuesday, September 18, 2012 2:50 AM > >> To: Robert Raszuk > >> Cc: idr wg; John Leslie > >> Subject: Re: [Idr] Comparison between session-reset and treat-as-withd= raw > >> > >> Hi Robert, > >> > >> Agree that bgp-operational-message could provide detailed diagnostic > >> information which would be quite helpful for diagnosing of > treat-as-withdraw > >> events. And some mechanism for automatic route recovery can also be > helpful > >> after some important routes are treat-as-withdraw. > >> > >> Regards, > >> Jie > >> > >> > -----Original Message----- > >> > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > Robert > >> > Raszuk > >> > Sent: Monday, September 17, 2012 3:37 PM > >> > To: Jie Dong > >> > Cc: John Leslie; Randy Bush; idr wg > >> > Subject: Re: [Idr] Comparison between session-reset and > >> > treat-as-withdraw > >> > > >> > All, > >> > > >> > Treat-as-withdraw was supposed to be used with > >> > bgp-operational-message. Using is as default before > >> > bgp-operational-message is available is IMHO a mistake. > >> > > >> > Regards, > >> > R. > >> > > >> > On Mon, Sep 17, 2012 at 9:29 AM, Jie Dong > wrote: > >> > > Hi John, > >> > > > >> > >> By which I guess he means that treat-as-withdraw has no > >> > >> automatic recovery path. And with that, I agree. > >> > > > >> > > Yes, that's exactly what I mean. > >> > > > >> > >> We may succeed in "routing around the problem" when we use > >> > >> treat-as-withdraw; but I think we may lack any way to restore the > >> > >> original route when the actual issue is resolved. > >> > >> > >> > >> And that, IMHO, deserves some discussion... > >> > > > >> > > Agreed, after using treat-as-withdraw on some routes, there will b= e > >> > > some > >> > inconsistency between the sending and receiving BGP speaker for some > >> > time, and some user traffic may be affected. Thus similar to session > >> > reset, maybe the receiving speaker could try to recover the particul= ar > >> > routes with some back-off mechanism before manual intervention. > >> > > > >> > > > >> > > Best regards, > >> > > Jie > >> > > > >> > >> -----Original Message----- > >> > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behal= f > >> > >> Of > >> > John > >> > >> Leslie > >> > >> Sent: Friday, September 14, 2012 11:00 PM > >> > >> To: Randy Bush > >> > >> Cc: idr wg > >> > >> Subject: Re: [Idr] Comparison between session-reset and > >> > >> treat-as-withdraw > >> > >> > >> > >> Randy Bush wrote: > >> > >> > [Enke Chen wrote:] > >> > >> > > >> > >> >> In terms of recovery, it has been shown that the session reset > >> > >> >> and reestablishment usually do not eliminate malformed updates= . > >> > >> >> Instead the session would often get into the cycle of reset an= d > >> > >> >> reestablishment until the culprit route is removed from the > >> > >> >> routing system by the operator manually. > >> > >> > > >> > >> > been there. have coffee cup and tee shirt. sadly sessions go > >> > >> > bouncy bouncy is not uncommon. > >> > >> > >> > >> Yes... major pain, and very little information about the actua= l > >> issue. > >> > >> > >> > >> But when the actual issue _is_ at the router getting the > >> > >> NOTIFICATION, we are "routing around the problem". > >> > >> > >> > >> We now are facing cases where the actual issue is elsewhere. > >> > >> > >> > >> Jie Dong wrote: > >> > >> ] > >> > >> ] If there is no session re-establishment after the session > >> > >> terminated, ] we may lose the chance of recovering the session > >> > >> automatically in ] some error cases. > >> > >> > >> > >> By which I guess he means that treat-as-withdraw has no > >> > >> automatic recovery path. And with that, I agree. > >> > >> > >> > >> We may succeed in "routing around the problem" when we use > >> > >> treat-as-withdraw; but I think we may lack any way to restore the > >> > >> original route when the actual issue is resolved. > >> > >> > >> > >> And that, IMHO, deserves some discussion... > >> > >> > >> > >> -- > >> > >> John Leslie > >> > >> _______________________________________________ > >> > >> Idr mailing list > >> > >> Idr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/idr > >> > > _______________________________________________ > >> > > Idr mailing list > >> > > Idr@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/idr > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Fri Sep 21 02:08:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F333621F8681 for ; Fri, 21 Sep 2012 02:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOsRTXTUrtJt for ; Fri, 21 Sep 2012 02:08:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8F7A21F86A1 for ; Fri, 21 Sep 2012 02:07:58 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3930279vcb.31 for ; Fri, 21 Sep 2012 02:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2lcE4SDE3D4+NkdsZhYHmPLu8ENLufyMlhClTg4iuyM=; b=k8yGXK8OKyQvwNYhLf5ZBopeK6wLviW4wwvnBvOuye89ls66tptytPbQpwdH54mGr5 SlOHnlpveODbUaPLpPrZzmxDZH2li4XazEVV8IIYiUbXtAw2Hr/gJX90MjGsy3VZENFh 6rqGnGyIjGYDDB776Yei5RZyyg7cRXg0ncEcH/HeJosI+VW6JmpnZ3ni8CEHQCsMo5qr /16DXp6dvMAMuPulspB8hlYGUofzU+5pZ+BA5grY1EFIvEjkhJedhHi3+SBlrQaznt93 LJ/9f3AuhY8H79KFWsepshrWIoF5yZ9DjaBY/DrR/WoUl9FbogM4DXV7Rdbn6WTL5p+0 DHUQ== MIME-Version: 1.0 Received: by 10.220.220.203 with SMTP id hz11mr2612301vcb.50.1348218477942; Fri, 21 Sep 2012 02:07:57 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 21 Sep 2012 02:07:57 -0700 (PDT) In-Reply-To: <505C0228.40805@raszuk.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> Date: Fri, 21 Sep 2012 05:07:57 -0400 X-Google-Sender-Auth: bxajCohK0UrDhaV-ID0KHs2FFxw Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:08:01 -0000 On Fri, Sep 21, 2012 at 1:59 AM, Robert Raszuk wrote: > Hi John, > > The proposal of dropping AS_PATH and the intention to completely replace it > with AS_SEC_PATH attribute has been negatively commented so many times in > the past both on idr and sidr that by bringing just one thread below seems > like erasing all other comments. > > The issues are not only related to routing .. they are also related to > number of BGP monitoring stations deployed today which use AS_PATH attribute > for real time BGP analysis. Do you expect all of those tools to change/be > updated when IETF will publish path validation RFC ? only if they are going to participate in the bgpsec specific parts... but then they'd already be set using just as_sec_path, right? we had this discussion (we == sidr-wg and I think idr?) several times already, essentially the as_sec_path only matters in the bubble that is 'bgpsec'. outside that bubble as_path still remains, and is re-manufactured as you cross the border by the exit-router at the bubble edge. The idea behind as_sec_path is really just a convenience of implementations so we don't have to maintain 2 identical (mostly) data structures in a device. Use as_path where you are not in the bubble, convert to as_sec_path at the bubble ingress, convert back to as_path at bubble exit. I don't see why this is as much of an issue, particularly for any monitoring code/station/system... if they don't do bgpsec, they just see the same data as they do today. no changes are required, operations continue, people stay happy... win? -chris > To only bring few past comments: > > http://www.ietf.org/mail-archive/web/sidr/current/msg04693.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04695.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04701.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04721.html > http://www.ietf.org/mail-archive/web/sidr/current/msg04722.html > > Regards, > R. > > >> Folks, >> >> FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This >> draft, assuming it progresses, represents a significant update to the >> BGP protocol, notably in terms of AS_PATH handling. If you haven't >> looked at it already, please consider taking the time to do so. >> >> Comments should go to both the sidr@ietf.org and idr@ietf.org mailing >> lists. >> >> There has already been some discussion of the draft on the sidr >> mailing list. Archives are here >> http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html >> >> --John >> >> P.S.: If you intend to review it but need more time, please speak up, >> and say how much more time you will need. >> >> Begin forwarded message: >> >>> From: "Murphy, Sandra" Subject: [sidr] >>> WGLC for draft-ietf-sidr-bgpsec-protocol-05 Date: September 15, >>> 2012 7:45:13 AM EDT To: "sidr@ietf.org" >>> >>> This starts a working group last call for >>> draft-ietf-sidr-bgpsec-protocol-05. The draft is available at >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>> >>> Please review this draft to see if you think it is ready for >>> publication. Send end comments to the list. >>> >>> The WGLC will end on 29 September 2012. >>> >>> --Sandy, speaking as wg co-chair >>> _______________________________________________ sidr mailing list >>> sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Fri Sep 21 02:13:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A621F871E for ; Fri, 21 Sep 2012 02:13:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpJccY2WAxZQ for ; Fri, 21 Sep 2012 02:13:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 19D1F21F871C for ; Fri, 21 Sep 2012 02:13:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TEzIz-000M3t-56; Fri, 21 Sep 2012 09:13:49 +0000 Date: Fri, 21 Sep 2012 18:13:48 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:13:52 -0000 > I don't see why this is as much of an issue, particularly for any > monitoring code/station/system... if they don't do bgpsec, they just > see the same data as they do today. no changes are required, > operations continue, people stay happy... win? sometimes, we will want to monitor the bgpsec aspects as well. and those monitors will do the capability negotiation for bgpsec, so will get bgpsec as_sec_paths, which is cool. randy From christopher.morrow@gmail.com Fri Sep 21 02:21:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1269821F865E for ; Fri, 21 Sep 2012 02:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSjRyNWqDxUo for ; Fri, 21 Sep 2012 02:21:41 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8BE21F8652 for ; Fri, 21 Sep 2012 02:21:41 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3944494vcb.31 for ; Fri, 21 Sep 2012 02:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gjjU3mUrrSW5YHySvepBzpRpEoodAGcYmztgnrZKdOE=; b=arDdnDz+ZT0REXQgYBeXggYKdd4son3TRV6M+2KPHJan6MM+f37VHLSVXX/fj5tiiM Uxk+O+o6qybxAk3HlNDQ5LjcXp1JS70NhGaY1EQW7JjoXBINz61jPCHvZEimNJQDDrRb qADsV0U/funTLKPiiPmvqm5mZsLqLleDxooOCdSYtgZ6OBLif+IIUSNsxJESBhl2qQD0 8YH0GvYUCla3kxO/h0uRSKVAMcMROJ9wLRrc2eqOL49vP0VF10mlHfzFD+h3FCrRAkgD ApQkbI9UvcFXYDjdHkvv9Dl3SRm7SI4nXXVvNfsIb5g80U6Vlz+uOI1wSumO31cm8P04 6Nig== MIME-Version: 1.0 Received: by 10.220.223.3 with SMTP id ii3mr2588885vcb.74.1348219300666; Fri, 21 Sep 2012 02:21:40 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 21 Sep 2012 02:21:40 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> Date: Fri, 21 Sep 2012 05:21:40 -0400 X-Google-Sender-Auth: P2H2Qz1p-5i9fTySsqawFF3cz5o Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:21:43 -0000 On Fri, Sep 21, 2012 at 5:13 AM, Randy Bush wrote: >> I don't see why this is as much of an issue, particularly for any >> monitoring code/station/system... if they don't do bgpsec, they just >> see the same data as they do today. no changes are required, >> operations continue, people stay happy... win? > > > > sometimes, we will want to monitor the bgpsec aspects as well. and > those monitors will do the capability negotiation for bgpsec, so will > get bgpsec as_sec_paths, which is cool. I thought I said that: "only if they are going to participate in the bgpsec specific parts... but then they'd already be set using just as_sec_path, right?" your pedantry is, of course, welcome... From jakob.heitz@ericsson.com Fri Sep 21 07:00:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B501B21F8835 for ; Fri, 21 Sep 2012 07:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdGE6m4wk+cp for ; Fri, 21 Sep 2012 07:00:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69821F8832 for ; Fri, 21 Sep 2012 07:00:20 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q8LE5mGh020092; Fri, 21 Sep 2012 09:05:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 21 Sep 2012 10:00:14 -0400 From: Jakob Heitz To: Christopher Morrow Date: Fri, 21 Sep 2012 10:00:14 -0400 Thread-Topic: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr Thread-Index: Ac2YAWuYWbvxhXvZR+eOPMSBawFJsQ== Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:00:20 -0000 The data that is forwarded does not need to follow the exact reverse path o= f the update message that carried the route. The update message can travers= e a different set of ASs than the update message. The BGP_SEC_PATH MUST des= cribe the path that the update message took. The AS_PATH describes the path= of the data, the chain of nexthops. Do we want to constrain the data path to be the same as the signaling path? That's like the Plain Old Telephone Signaling (POTS). In modern networks, l= ike SS7, the signaling takes a different path than the data. -- Jakob Heitz. On Sep 21, 2012, at 2:21 AM, "Christopher Morrow" = wrote: > On Fri, Sep 21, 2012 at 5:13 AM, Randy Bush wrote: >>> I don't see why this is as much of an issue, particularly for any >>> monitoring code/station/system... if they don't do bgpsec, they just >>> see the same data as they do today. no changes are required, >>> operations continue, people stay happy... win? >>=20 >> >>=20 >> sometimes, we will want to monitor the bgpsec aspects as well. and >> those monitors will do the capability negotiation for bgpsec, so will >> get bgpsec as_sec_paths, which is cool. >=20 > I thought I said that: > "only if they are going to participate in the bgpsec specific parts... > but then they'd already be set using just as_sec_path, right?" >=20 > your pedantry is, of course, welcome... > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Fri Sep 21 07:13:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30D21F8832 for ; Fri, 21 Sep 2012 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbdb4pjERUr6 for ; Fri, 21 Sep 2012 07:13:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 741F121F8831 for ; Fri, 21 Sep 2012 07:13:55 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4289772vcb.31 for ; Fri, 21 Sep 2012 07:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hgTKttnUU7i+pgk9IZg4AfVACUILcspLCf8jW6Bw9kQ=; b=VtB8dnvkUm9pIRhxgFVL0AmLOUk64uWA21N0YiOetZcKgp0wYOuXlPIMVPcJ2GyPrc 9J4Jt/DniBD7l1HAV8ITJiN8eOJ61uiqXwH5hgcT99mjc0dqKAL0Ljc2lC5KsaAlETou zhdUZ3pUHH+tJ5yhD4MYfO4lOSpG6RN1iFURrWqrLu0n2Z+UBu67yfRys0SGRus46PW/ yEQUOmoJwkn8+VMGZRK7EPrk7o42mmNWTcpzeJ7RirD6bGGogvTItaGKlEgGzHBwPhBh ckUKwOMZB0+aEjm2s1bB02RXwPa3dkSXYPLyYBGQH/HKiYwF/akRWxbuUoTR+eIv8dNw DhnA== MIME-Version: 1.0 Received: by 10.220.210.135 with SMTP id gk7mr3085285vcb.13.1348236834500; Fri, 21 Sep 2012 07:13:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 21 Sep 2012 07:13:54 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> Date: Fri, 21 Sep 2012 10:13:54 -0400 X-Google-Sender-Auth: i2E5NVenMMaF0O51PKTIPSjiraw Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:13:56 -0000 On Fri, Sep 21, 2012 at 10:00 AM, Jakob Heitz wrote: > The data that is forwarded does not need to follow the exact reverse path of the update message that carried none of the SIDR work is about 'data that is forwarded', it's about the routing system, not the data path. > the route. The update message can traverse a different set of ASs than the update message. The this sentence isn't correct, did you mean: "The update message can traverse a different set of ASs than what is represented in the update message" ? I'd agree with that, you can, today, lie/cheat/steal in the AS_PATH attribute. I don't think that's a proper thing to do, no. > BGP_SEC_PATH MUST describe the path that the update message took. The AS_PATH describes the path > of the data, the chain of nexthops. no, the AS_PATH today, describes MOST OFTEN (but not ALWAYS) the path that the update message took through the routing system. People can (and do, sometimes) wrangle with the AS_PATH for their own reasons, without anyone else being the wiser. You are correct that the intent of BGPSEC is to provide a validated path on which the update message passed. > Do we want to constrain the data path to be the same as the signaling path? this isn't constraining the data path. > That's like the Plain Old Telephone Signaling (POTS). In modern networks, like SS7, the signaling takes a different path than the data. > this isn't POTS, nor SS7... this is bgp and the internet. -chris > Jakob Heitz. > > > On Sep 21, 2012, at 2:21 AM, "Christopher Morrow" wrote: > >> On Fri, Sep 21, 2012 at 5:13 AM, Randy Bush wrote: >>>> I don't see why this is as much of an issue, particularly for any >>>> monitoring code/station/system... if they don't do bgpsec, they just >>>> see the same data as they do today. no changes are required, >>>> operations continue, people stay happy... win? >>> >>> >>> >>> sometimes, we will want to monitor the bgpsec aspects as well. and >>> those monitors will do the capability negotiation for bgpsec, so will >>> get bgpsec as_sec_paths, which is cool. >> >> I thought I said that: >> "only if they are going to participate in the bgpsec specific parts... >> but then they'd already be set using just as_sec_path, right?" >> >> your pedantry is, of course, welcome... >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Fri Sep 21 07:22:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2973D21F884E for ; Fri, 21 Sep 2012 07:22:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTwPOfUG+bn8 for ; Fri, 21 Sep 2012 07:21:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C793D21F8819 for ; Fri, 21 Sep 2012 07:21:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TF478-000Mt1-Pj; Fri, 21 Sep 2012 14:21:55 +0000 Date: Fri, 21 Sep 2012 23:21:53 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <505C0228.40805@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:22:00 -0000 > Do we want to constrain the data path to be the same as the signaling > path? ideally as an option, sure. send code :) randy From danny@tcb.net Sat Sep 22 11:08:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F621F8679 for ; Sat, 22 Sep 2012 11:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buoq0ieyBJRa for ; Sat, 22 Sep 2012 11:08:55 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5661621F8697 for ; Sat, 22 Sep 2012 11:08:55 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 795542680C7; Sat, 22 Sep 2012 12:08:47 -0600 (MDT) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 22 Sep 2012 12:08:46 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.171.124.149; client-port=54248; syn-fingerprint=65535:48:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Sat, 22 Sep 2012 14:08:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> To: John G. Scudder X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 18:08:56 -0000 On Sep 20, 2012, at 7:38 PM, John G. Scudder wrote: >=20 > P.S.: If you intend to review it but need more time, please speak up, = and say how much more time you will need. I intend to review it, but would prefer that the SIDR WG complete the = threat and requirements documents before progressing the solutions = specifications that muck considerably with BGP. I also think the work on BGPSEC might be better done in IDR, where IDR = expertise and a wider set of perspectives exists to give appropriate = consideration to things that will certainly impact the security and = stability of the global routing system, whether specific elements are = BGPSEC enabled or not. -danny From wesley.george@twcable.com Mon Sep 24 06:11:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE7D21F869E for ; Mon, 24 Sep 2012 06:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFJu-UkaKE7i for ; Mon, 24 Sep 2012 06:11:06 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8A54A21F8683 for ; Mon, 24 Sep 2012 06:11:06 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,475,1344225600"; d="scan'208";a="424836290" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Sep 2012 09:10:09 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 24 Sep 2012 09:11:05 -0400 From: "George, Wes" To: "idr@ietf.org" Date: Mon, 24 Sep 2012 09:11:04 -0400 Thread-Topic: New Version Notification for draft-ga-idr-as-migration-00.txt Thread-Index: Ac2aVaf9m7Pu1w+oTl+N2XA+iw2nvwAAB4rQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> References: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> In-Reply-To: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "shane@castlepoint.net" Subject: [Idr] FW: New Version Notification for draft-ga-idr-as-migration-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:11:07 -0000 TmV3IGRyYWZ0IGZvciB5b3VyIHJldmlldy4gVGhpcyBpcyByZWxhdGVkIHRvIGEgZGlzY3Vzc2lv biB3ZSd2ZSBiZWVuIGhhdmluZyBpbiBTSURSLCBidXQgc2luY2UgdGhpcyBwcm9jZWR1cmUgaXMg bm90IHNwZWNpZmljIHRvIFNJRFIsIHdlIHRob3VnaHQgaXQgYmVzdCB0byBkb2N1bWVudCB0aGUg cHJvY2VkdXJlIGFuZCBmZWF0dXJlcyB1c2VkIGR1cmluZyBhbiBBU04gbWlncmF0aW9uIGhlcmUs IGFuZCB0aGVuIFNJRFIgd2lsbCBuZWVkIHRvIHNpbXBseSBkZXRlcm1pbmUgdGhlIGJlc3Qgd2F5 IHRvIHN1cHBvcnQgdGhpcy4NCg0KVGhpcyBpcyBjdXJyZW50bHkgYW4gaW5mb3JtYXRpb25hbCBJ RCwgYnV0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGEgUFMgYXMgd2VsbC4NCg0KVGhhbmtzLA0KDQpX ZXMgR2VvcmdlIGFuZCBTaGFuZSBBbWFudGUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTIgOTowOCBBTQ0KVG86 IEdlb3JnZSwgV2VzDQpDYzogc2hhbmVAbGV2ZWwzLm5ldA0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1nYS1pZHItYXMtbWlncmF0aW9uLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1nYS1pZHItYXMtbWlncmF0aW9uLTAwLnR4dCBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlc2xleSBHZW9yZ2UgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWdhLWlkci1h cy1taWdyYXRpb24NClJldmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgQXV0b25v bW91cyBTeXN0ZW0gKEFTKSBNaWdyYXRpb24gRmVhdHVyZXMgYW5kIFRoZWlyIEVmZmVjdHMgb24g dGhlIEJHUCBBU19QQVRIIEF0dHJpYnV0ZQ0KQ3JlYXRpb24gZGF0ZTogICAyMDEyLTA5LTI0DQpX RyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAx MA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1nYS1pZHItYXMtbWlncmF0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdhLWlkci1hcy1taWdyYXRpb24NCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2EtaWRyLWFzLW1p Z3JhdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkaXNjdXNzZXMgY29tbW9u IG1ldGhvZHMgb2YgbWFuYWdpbmcgYW4gQVNOIG1pZ3JhdGlvbg0KICAgdXNpbmcgc29tZSBCR1Ag ZmVhdHVyZXMgdGhhdCB3aGlsZSBjb21tb25seS11c2VkIGFyZSBub3QgZm9ybWFsbHkNCiAgIHBh cnQgb2YgdGhlIEJHUDQgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhbmQgbWF5IGJlIHZlbmRvci1z cGVjaWZpYyBpbg0KICAgZXhhY3QgaW1wbGVtZW50YXRpb24uICBJdCBpcyBuZWNlc3NhcnkgdG8g ZG9jdW1lbnQgdGhlc2UgZGUgZmFjdG8NCiAgIHN0YW5kYXJkcyB0byBlbnN1cmUgdGhhdCB0aGV5 IGFyZSBwcm9wZXJseSBzdXBwb3J0ZWQgaW4gQkdQU2VjLg0KDQoNCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBj b250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUt bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBw ZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFp bCBhbmQgYW55IHByaW50b3V0Lg0K From pierre.francois@imdea.org Wed Sep 26 01:50:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1459921F87DD; Wed, 26 Sep 2012 01:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vghsWoRu9n-F; Wed, 26 Sep 2012 01:50:28 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0921F8793; Wed, 26 Sep 2012 01:50:26 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 1803A2633DD; Wed, 26 Sep 2012 10:50:25 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id j08xP-qSWNjE; Wed, 26 Sep 2012 10:50:21 +0200 (CEST) Received: from pierre.networks.imdea.org (unknown [193.145.14.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id 5EB3F2633DC; Wed, 26 Sep 2012 10:50:21 +0200 (CEST) Message-ID: <5062C1CD.7050702@imdea.org> Date: Wed, 26 Sep 2012 10:50:21 +0200 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: 'IETF IDR' , "grow@ietf.org" References: <20120925192146.20786.32535.idtracker@ietfa.amsl.com> In-Reply-To: <20120925192146.20786.32535.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120925192146.20786.32535.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000007050803070103000909" Subject: [Idr] Fwd: I-D Action: draft-cardona-filtering-threats-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:50:29 -0000 This is a multi-part message in MIME format. --------------000007050803070103000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear grow and idr members, Recent talks at network operators group meetings, as well as proposals at the IETF, acknowledge the need of operators to filter overlapping prefixes (be it to reduce their routing table size or their bill). This document lists various cases where a filtering of overlapping prefixes performed within one AS triggers a violation of the policies that other ASes implement in their network. The simplicity of those cases motivated us to warn operators for the risks associated with such filtering, as they seem likely to happen if overlapping prefix filtering is becoming an habit rather than a punctual, exceptionally applied measure. This draft acknowledges the motivation for such filtering, and thus tries to foster attention on the potential risks from ISPs and vendors applying, planning to apply, or designing routing features to facilitate such filtering. The draft covers cases where the filtering is performed locally by an AS, as well as cases where the filtering is triggered remotely through the use of BGP communities commonly defined for that purpose. We would like to adapt this initial draft based on the comments and feedback received from you, before presenting it at the next IETF meeting. Regards, Pierre Francois. -------- Original Message -------- Subject: I-D Action: draft-cardona-filtering-threats-00.txt Date: Tue, 25 Sep 2012 12:21:46 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Making BGP filtering an habit: Impact on policies Author(s) : Pierre Francois Camilo Cardona Filename : draft-cardona-filtering-threats-00.txt Pages : 17 Date : 2012-09-25 Abstract: This draft describes potential threats to the Internet routing policies of an autonomous system due to filtering of more specific BGP prefixes by its neighboring domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cardona-filtering-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-cardona-filtering-threats-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000007050803070103000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear grow and idr members,

Recent talks at network operators group meetings, as well as proposals at the IETF, acknowledge the need of operators to filter overlapping prefixes (be it to reduce their routing table size or their bill).

This document lists various cases where a filtering of overlapping prefixes performed within one AS triggers a violation of the policies that other ASes implement in their network. The simplicity of those cases motivated us to warn operators for the risks associated with such filtering, as they seem likely to happen if overlapping prefix filtering is becoming an habit rather than a punctual, exceptionally applied measure.

This draft acknowledges the motivation for such filtering, and thus tries to foster attention on the potential risks from ISPs and vendors applying, planning to apply, or designing routing features to facilitate such filtering.

The draft covers cases where the filtering is performed locally by an AS, as well as cases where the filtering is triggered remotely through the use of BGP communities commonly defined for that purpose.

We would like to adapt this initial draft based on the comments and feedback received from you, before presenting it at the next IETF meeting.

Regards,

Pierre Francois.


-------- Original Message --------
Subject: I-D Action: draft-cardona-filtering-threats-00.txt
Date: Tue, 25 Sep 2012 12:21:46 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Making BGP filtering an habit: Impact on policies
	Author(s)       : Pierre Francois
                          Camilo Cardona
	Filename        : draft-cardona-filtering-threats-00.txt
	Pages           : 17
	Date            : 2012-09-25

Abstract:
   This draft describes potential threats to the Internet routing
   policies of an autonomous system due to filtering of more specific
   BGP prefixes by its neighboring domains.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-cardona-filtering-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-cardona-filtering-threats-00


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--------------000007050803070103000909-- From wwwrun@rfc-editor.org Wed Sep 26 02:10:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BE521F8813 for ; Wed, 26 Sep 2012 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cN+6miJKXSW for ; Wed, 26 Sep 2012 02:10:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBF221F8658 for ; Wed, 26 Sep 2012 02:10:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 84AD3B1E002; Wed, 26 Sep 2012 02:06:55 -0700 (PDT) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20120926090655.84AD3B1E002@rfc-editor.org> Date: Wed, 26 Sep 2012 02:06:55 -0700 (PDT) X-Mailman-Approved-At: Wed, 26 Sep 2012 08:47:39 -0700 Cc: shtyagi@microsoft.com, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 09:10:56 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 -------------------------------------- Type: Technical Reported by: Shashank Tyagi Section: 8.2.2 Original Text ------------- If a TcpConnectionFails event (Event 18) is received, the local system: - closes the BGP connection, - restarts the ConnectRetryTimer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Corrected Text -------------- If a TcpConnectionFails event (Event 18) is received, the local system: - closes the BGP connection, - sets the HoldTimer to 0, - restarts the ConnectRetryTimer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Notes ----- HoldTimer should only be used to control time in between BGP packets. Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From danny@tcb.net Wed Sep 26 09:27:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1DB21F8527 for ; Wed, 26 Sep 2012 09:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj+1BypQCKDB for ; Wed, 26 Sep 2012 09:27:08 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2C53021F84F8 for ; Wed, 26 Sep 2012 09:27:08 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id ABB3A2680C7; Wed, 26 Sep 2012 10:27:07 -0600 (MDT) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 26 Sep 2012 10:27:07 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=10143; syn-fingerprint=65535:53:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson X-Priority: Normal In-Reply-To: <571358400-1348663504-cardhu_decombobulator_blackberry.rim.net-1797235029-@b12.c6.bise6.blackberry> Date: Wed, 26 Sep 2012 12:27:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67BAB02A-12B3-46C3-B660-66A93BDCCB0D@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <571358400-1348663504-cardhu_decombobulator_blackberry.rim.net-1797235029-@b12.c6.bise6.blackberry> To: shares@ndzh.com X-Mailer: Apple Mail (2.1283) Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:27:08 -0000 On Sep 26, 2012, at 4:01 AM, shares@ndzh.com wrote: > Danny: >=20 > I would suggest the following things prior to accepting this change >=20 > 1) Your proposal for threat analysis and requirements, > 2) Deployments reports on interoperability on this feature, > 3) Transition reports - in and out of bgpsecure zone. > 4) Scaling in deployment >=20 > What do think? Besides not being sure what "bgpsecure zone" is, yes -- these certainly = seem like the kind of things that IDR and folks that operate = BGP-speaking routers that this work _will impact should be asking. =20 -danny From stephane.litkowski@orange.com Thu Sep 27 05:19:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A077421F8585 for ; Thu, 27 Sep 2012 05:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6jN8Kx8i+ix for ; Thu, 27 Sep 2012 05:19:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C06D321F8584 for ; Thu, 27 Sep 2012 05:19:50 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7FE3918C25F; Thu, 27 Sep 2012 14:19:49 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 63DE127C079; Thu, 27 Sep 2012 14:19:49 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.64.14.45]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 27 Sep 2012 14:19:49 +0200 From: To: "George, Wes" , "idr@ietf.org" Date: Thu, 27 Sep 2012 14:19:47 +0200 Thread-Topic: [Idr] FW: New Version Notification for draft-ga-idr-as-migration-00.txt Thread-Index: Ac2aVaf9m7Pu1w+oTl+N2XA+iw2nvwAAB4rQAJToXiA= Message-ID: <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr> References: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.27.110319 Cc: "shane@castlepoint.net" Subject: Re: [Idr] FW: New Version Notification for draft-ga-idr-as-migration-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:19:51 -0000 Hi Wes, and Shane, Good idea to describe such migration situations and required features, as y= ou mention, not all implementations have these features. I pretty agree on what is described but I think more diagrams would be help= ful to clarify. The main point is that today you are only taking into account (but it's jus= t a first shot of draft :) ) the AS merge case, but AS renumbering case is = also very interresting (we done it :) ) as it may require the "allow-as in"= or "as-loop" feature and the scenario is a bit difference as you have to m= anage inter AS gateways (old and new AS). It would be helpful to have the draft as PS in order to have such features = as MUST or SHOULD within BGP implementations. PS : Being able to change AS number in router configuration without deletin= g all BGP config would be helpful also :) Best Regards, Stephane -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Georg= e, Wes Envoy=E9 : lundi 24 septembre 2012 15:11 =C0 : idr@ietf.org Cc : shane@castlepoint.net Objet : [Idr] FW: New Version Notification for draft-ga-idr-as-migration-00= .txt New draft for your review. This is related to a discussion we've been havin= g in SIDR, but since this procedure is not specific to SIDR, we thought it = best to document the procedure and features used during an ASN migration he= re, and then SIDR will need to simply determine the best way to support thi= s. This is currently an informational ID, but could potentially be a PS as wel= l. Thanks, Wes George and Shane Amante -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, September 24, 2012 9:08 AM To: George, Wes Cc: shane@level3.net Subject: New Version Notification for draft-ga-idr-as-migration-00.txt A new version of I-D, draft-ga-idr-as-migration-00.txt has been successfull= y submitted by Wesley George and posted to the IETF repository. Filename: draft-ga-idr-as-migration Revision: 00 Title: Autonomous System (AS) Migration Features and Their Effect= s on the BGP AS_PATH Attribute Creation date: 2012-09-24 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ga-idr-as-migrat= ion-00.txt Status: http://datatracker.ietf.org/doc/draft-ga-idr-as-migration Htmlized: http://tools.ietf.org/html/draft-ga-idr-as-migration-00 Abstract: This draft discusses common methods of managing an ASN migration using some BGP features that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in BGPSec. The IETF Secretariat This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From shane@castlepoint.net Thu Sep 27 19:27:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15DA21F8530 for ; Thu, 27 Sep 2012 19:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRX+wIl5mWGX for ; Thu, 27 Sep 2012 19:27:13 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id F3C4621F84CE for ; Thu, 27 Sep 2012 19:27:12 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 86E48F5; Thu, 27 Sep 2012 20:27:09 -0600 (MDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr> Date: Thu, 27 Sep 2012 20:27:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr> To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1498) Cc: "idr@ietf.org" , "George, Wes" Subject: Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 02:27:13 -0000 Hi Stephane, On Sep 27, 2012, at 6:19 AM, stephane.litkowski@orange.com wrote: > Hi Wes, and Shane, >=20 > Good idea to describe such migration situations and required features, = as you mention, not all implementations have these features. > I pretty agree on what is described but I think more diagrams would be = helpful to clarify. Could you clarify what more diagrams might help with? We tried to = simplify the diagram to depict the effects on the AS_PATH attribute as = it traverse ASN's with these features enabled. Hopefully, we struck the = right balance there, although suggestions are welcome on how we could = improve them. > The main point is that today you are only taking into account (but = it's just a first shot of draft :) ) the AS merge case, but AS = renumbering case is also very interresting (we done it :) ) as it may = require the "allow-as in" or "as-loop" feature and the scenario is a bit = difference as you have to manage inter AS gateways (old and new AS). > It would be helpful to have the draft as PS in order to have such = features as MUST or SHOULD within BGP implementations. That's a good point. Due to the short time we had to write & publish = this draft, we only could document what's in the current draft. I do = plan to add some other ASN migration features in a next rev of this = draft, but had not considered those two. Thanks for the suggestion; = we'll see what we can do. =20 > PS : Being able to change AS number in router configuration without = deleting all BGP config would be helpful also :) Fortunately, some vendors got this right. =20 -shane > Best Regards, >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de = George, Wes > Envoy=E9 : lundi 24 septembre 2012 15:11 > =C0 : idr@ietf.org > Cc : shane@castlepoint.net > Objet : [Idr] FW: New Version Notification for = draft-ga-idr-as-migration-00.txt >=20 > New draft for your review. This is related to a discussion we've been = having in SIDR, but since this procedure is not specific to SIDR, we = thought it best to document the procedure and features used during an = ASN migration here, and then SIDR will need to simply determine the best = way to support this. >=20 > This is currently an informational ID, but could potentially be a PS = as well. >=20 > Thanks, >=20 > Wes George and Shane Amante >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, September 24, 2012 9:08 AM > To: George, Wes > Cc: shane@level3.net > Subject: New Version Notification for draft-ga-idr-as-migration-00.txt >=20 >=20 > A new version of I-D, draft-ga-idr-as-migration-00.txt has been = successfully submitted by Wesley George and posted to the IETF = repository. >=20 > Filename: draft-ga-idr-as-migration > Revision: 00 > Title: Autonomous System (AS) Migration Features and Their = Effects on the BGP AS_PATH Attribute > Creation date: 2012-09-24 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-ga-idr-as-migration-00.txt > Status: = http://datatracker.ietf.org/doc/draft-ga-idr-as-migration > Htmlized: = http://tools.ietf.org/html/draft-ga-idr-as-migration-00 >=20 >=20 > Abstract: > This draft discusses common methods of managing an ASN migration > using some BGP features that while commonly-used are not formally > part of the BGP4 protocol specification and may be vendor-specific = in > exact implementation. It is necessary to document these de facto > standards to ensure that they are properly supported in BGPSec. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 >=20