Re: [Idr] draft-chen-bgp-redist-01.txt
Alejandro Acosta <alejandroacostaalamo@gmail.com> Sat, 03 July 2021 13:21 UTC
Return-Path: <alejandroacostaalamo@gmail.com>
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 99BAE3A1441 for <idr@ietfa.amsl.com>; Sat, 3 Jul 2021 06:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level:
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyCFTJNHb19k for <idr@ietfa.amsl.com>; Sat, 3 Jul 2021 06:21:52 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2C43A143D for <idr@ietf.org>; Sat, 3 Jul 2021 06:21:51 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id q101so1852695qvq.5 for <idr@ietf.org>; Sat, 03 Jul 2021 06:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=OXR9HX4NPg15o+rQ2UvRjwWV23Yh9pV1EX3sBpZosOc=; b=kZFm3H8HR1EXNnG7Zj1/nX3LGDZB1Y03cG8fIT/A77FNErM3IwCMt8rHAUn7YTQDfy Qt9yG86eqvnZTR7W9v6JIL3XWro6V+YN8L+EBHrkCiYHdgaQj9NeiJae8z0BzGr3nke9 CFMgQz6tJOq59DQEYkijbWILtmA+v+u0CeIMQNndFf6HM9eCqmPXYqzjZztJlDZr7nzo uDbt1zYMeb0cVY/dmJCbv8wah64Ik0ukicSgI54NADcELICQWO1Mxleey/uMDPD4kZnz 9GR8yERuXeuF5Vd5evlqBxm3bR7osNzRnGoUb9a4Hh/09ukbJ8H5aPkycqCvgmTlKq93 U3VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=OXR9HX4NPg15o+rQ2UvRjwWV23Yh9pV1EX3sBpZosOc=; b=GG2Sv/y1K1pXpyJdJfX+PVWMbMNGsRAff4WYtibjF31eB5OEsC09Aw6QmR+vSgx/Hz Mf7zlEQfpgsTVAuNfcCd/2iTxuO8LEq14dxfm35e1fhcdXLT0rPoqUkSc1gNvF0JjwRy 3cw1P3Kf99+7fJ7wox8Gka+aiS7VsgGUuTQwZQrE5vZI589RYrjVv1FXamtEvRs39Qm4 Z5EYKvPF0edMZndtB1ivyCy1gG/WF6pJkniAlGUumDCjidymygKrO614DnEb6xNHJs5p 02+34mMU6NjFr/v9mo/62xRXRmlUSyv6jYTsLbF2Hulpm6Qx21iic4DCcf0lt4NjC2ka ZpZA==
X-Gm-Message-State: AOAM532Y/G3+llDOLMze9+Dy3dRS0CBqnCop5xC5WYqUbXLvikDAWHKQ eI5pIrKYq9viT3AmKOHLICI=
X-Google-Smtp-Source: ABdhPJweAXZ0+M+37NHUvXLZrV+HT9SbZjqbyxnzZJ8tq1roOAQ9/xxVBObk6Ab5czoKmtKFJI7Mug==
X-Received: by 2002:a0c:b38c:: with SMTP id t12mr4691748qve.44.1625318509365; Sat, 03 Jul 2021 06:21:49 -0700 (PDT)
Received: from [192.168.1.75] ([200.8.214.52]) by smtp.gmail.com with ESMTPSA id h11sm2928247qko.25.2021.07.03.06.21.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jul 2021 06:21:48 -0700 (PDT)
From: Alejandro Acosta <alejandroacostaalamo@gmail.com>
To: idr@ietf.org
References: <CANJ8pZ_2yk666tSca818-e0YdziKjK3dMqhopOtYAP3vKXTEmQ@mail.gmail.com> <CAOj+MME5zZeZDnhpfivbdKj00JwBzi9rjMmzBXxE_fFqkxEVpA@mail.gmail.com> <CANJ8pZ9Und3fF324tzTAkhrMFV0MZfhHYfZussiYSCNUx-n_Hw@mail.gmail.com> <CABNhwV3BXk=+fuxVSg_9j+u+5Ffr+NQGE9P75NCPpTaUr5LqYQ@mail.gmail.com> <CAOj+MMFxM_yvrPDEyQ+dpO7ZxoiQKa0DE4ZQf763Cuidj76QXg@mail.gmail.com> <CABNhwV1q-H1pSypWCvA9VKXBZZTfM3nQNPktjbmbN0D=VSXpBw@mail.gmail.com> <CABNhwV29-t-N6EMmJQzOairgTB5jsPX1h6Q0e+akEgiA2cUpQg@mail.gmail.com> <CABNhwV1QAR8qHdP+rSTOk3eRU5A5tMAfWFFyqXYPQteHtoNyBg@mail.gmail.com> <BYAPR11MB3207B8AE524F71ED25590B94C01F9@BYAPR11MB3207.namprd11.prod.outlook.com> <e6a5ac64-c948-a08e-079f-47f63dd1b787@gmail.com>
Message-ID: <fc5890f4-3328-a22d-4ff5-f7672911f0b4@gmail.com>
Date: Sat, 03 Jul 2021 09:21:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <e6a5ac64-c948-a08e-079f-47f63dd1b787@gmail.com>
Content-Type: multipart/alternative; boundary="------------C1371177FB2E6E46DDFDB664"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oZh5_DU3ffXGd9sPrxvUdWHvE2g>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2021 13:21:58 -0000
Hello, As I said before I created a small lab with three routers, just for testing purposes. Even when the draft is not 100% aimed for BGP I have to say one finding (well, maybe you are already aware but at I did not catched it when reading the draft) that I believe is important. In this scenario: R1 -- R2 -- R3 R1 (AS65001) is announcing 10.0.0.1 (eBGP, AD 20) R2 (AS65002) has a static floating (AD 150) route pointing to 10.0.0.1 toward R1. R3 Learns 10.0.0.1 via R2 and the AS_Origin is set to 65001 (in case there is a ROA, RPKI would be fine) Suppose eBGP session resets between R1 & R2, static floating route takes places. Now R3 learns 10.0.0.1 but AS_Origin is AS 65002 (RPKI fails !!.., routing valid, prefix dropped, etc. ) Two more comments: Even when the eBGP session goes up RIB & BGP in R2 remains static for 10.0.0.1 Even when the eBGP session goes up RIB & BGP in R3 AS_Path still indicating 65001 as AS_ORIGIN Well, hope it helps and I made myself understood. Thanks, Alejandro, On 2/7/21 8:50 PM, Alejandro Acosta wrote: > > > On 2/7/21 2:33 AM, Jakob Heitz (jheitz) wrote: >> >> Admin-distance is not defined in any RFCs. It is a vendor only concept. >> >> I can speak about it from the Cisco IOS-XR and Redback perspective. >> >> In both of these implementations, RIB and BGP are separate processes >> >> with separate memory spaces and their own routing tables. >> >> Routes are passed between them using inter-process communication >> messages. >> >> They cannot access each other's routing tables. Other routing protoclos, >> >> such as OSPF, ISIS and static are also separate processes. Each of >> the routing >> >> protocols downloads their valid routes to RIB. If the same IP prefix is >> >> sent to RIB by multiple routing protocols, RIB will select one to be used >> >> for forwarding and resolving nexthops. RIB uses admin-distance to decide. >> >> Routing protocols get their local routes from RIB. >> >> A static route has admin-distance of 1 by default. >> >> However, a static route can be configured with a different >> admin-distance. >> >> It is possible to configure a backup static route by configuring a high >> >> admin-distance for it. >> >> In that case, if another route is found for the given prefix by another >> >> routing protocol, say an ISIS route, then the ISIS route will be used >> >> for forwarding. Only if the ISIS route disappears will the backup static >> >> route be used. >> >> Now, suppose we want to advertise that prefix in BGP. We can do that >> >> with a "redistribute" statement or with a "network" statement. >> >> They work a little bit differently, but either command will import >> >> the route from the RIB into BGP. >> >> Once the route is in BGP, it loses its admin-distance. >> >> BGP has no knowledge of the admin-distance that this route had in RIB. >> >> There is no admin-distance in section 9.1 of RFC 4271. >> >> This is the root of the problem that Enke and Jenny are trying to solve. >> >> The problem occurs if the same prefix can be learnt by BGP from >> >> a BGP peer. BGP may download it into RIB. The draft addresses the >> >> different outcome if BGP learns the route first from it peer or learns >> >> it first from the local RIB. >> > > To be honest after reading the draft I still had my doubts. > > I just tested it (using old Cisco gear) and the behavior was exactly > the described in draft. Having said that I have to admit that at the > beginning I was skeptical about this, but now I believe this draft > deserve further discussions. > > > Thanks, > > > Alejandro, > > > > >> Regards, >> >> Jakob. >> >> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Gyan Mishra >> *Sent:* Thursday, July 1, 2021 6:18 PM >> *To:* Robert Raszuk <robert@raszuk.net> >> *Cc:* idr@ietf. org <idr@ietf.org>; Jenny Yuan >> <jyuan@paloaltonetworks.com> >> *Subject:* Re: [Idr] draft-chen-bgp-redist-01.txt >> >> From a network design POV, in general within a an IP transit AS their >> is no need to redistribute BGP into IGP unless their are non BGP >> speaking routers within the network. >> >> As for sourcing routes into BGP advertisement from a customer edge >> best practice is to originate the advertisement as close to the >> source routers as possible, and if it’s a summary then use a network >> statement and if LPM routes are required then redistribution of IGP >> into BGP via policy is the best way but also as close to the source >> of the prefixes. >> >> From a core perspective IP or MPLS it is common to redistribute >> connected or IGP into BGP global table still separate from customer >> traffic in SP operator core where MPLS any-any VPN VRF is used to >> carry Internet traffic and in that case the NOC may sit in the >> Internet VRF and NMS systems need telemetry access back to the global >> table. >> >> Kind Regards >> >> Gyan >> >> On Thu, Jul 1, 2021 at 8:56 PM Gyan Mishra <hayabusagsm@gmail.com >> <mailto:hayabusagsm@gmail.com>> wrote: >> >> Hi Enke >> >> I am still trying to understand the need for this draft. >> >> Their are two main methods to locally originate routes into BGP >> done at the customer edge which is via redistribution or network >> statement. When you redistribute routes into BGP the origin flag >> is set to incomplete. When you use a network statement with >> exact match of prefix installed in the RIB, the route origin >> changes to IGP origin. The pecking order for Orgin is EGP, IGP, >> Incomplete so if the routes is also advertised via network >> statement and redistribution by two different ASBR the best path >> selection will converge on the best path IGP origin via network >> statement over redistribution. Maybe that is the intention of >> the draft to prefer incomplete over IGP origin and that can be >> set via policy as well so that both are equal so load balancing >> can occur. >> >> At the bottom of page 2 below is stated as the premise for this >> draft. >> >> Currently the admin-distance does not play any role in BGP route >> >> selection. >> >> I disagree. Indeed AD plays an important role in redistribution >> or locally sourcing of prefixes into BGP advertisement. All >> vendor implementations do this the same way and that is that only >> the lowest AD source >> >> Of a particular prefix is what is installed onto the RIB and >> FIB. So when doing either a redistribution or using network >> statement exact match to source local routes into a BGP >> advertisement only the prefixes installed in the RIB that match >> exactly via network statement or if you have a redistribution >> policy matches the prefix and source protocol for the route being >> redistributed. >> >> Let’s say you have a redistributing OSPF into BGP however their >> is a static route exact match for the prefix you want to >> redistribute that matches your redistribution prefix list >> >> however as OSPF has AD 110 and static had AD 1 default and if you >> are trying to redistribute ospf into BGP the redistribution will >> not work since the RIB has the static route as the source for the >> prefix installed in the RIB. >> >> Example of how AD plays an important role in how redistribution >> can or may not occur properly due to AD of the protocol sourcing >> the prefix >> >> And the protocol being redistributed must match or the >> redistribution will fail. >> >> I have noticed one issue with both redistribution and network >> statement which is problematic is that the IGP metric is passed >> into BGP as MED which is higher in the BGP best path selection >> which can result in sub optimal routing. The workaround is to >> reset MED to 0 with a policy. >> >> Kind Regards >> >> Gyan >> >> On Thu, Jul 1, 2021 at 8:23 PM Gyan Mishra <hayabusagsm@gmail.com >> <mailto:hayabusagsm@gmail.com>> wrote: >> >> The main protocols are BGP, OSPF, ISIS, Static >> >> Juniper >> >> https://www.juniper.net/documentation/en_US/junose15.1/topics/task/configuration/ip-route-administrative-distance-configuration.html >> <https://www.juniper.net/documentation/en_US/junose15.1/topics/task/configuration/ip-route-administrative-distance-configuration.html> >> >> Route Source >> >> >> >> Default Distance >> >> Connected interface >> >> >> >> 0 >> >> Static route >> >> >> >> 1 >> >> Internal access route >> >> >> >> 2 >> >> Access route >> >> >> >> 3 >> >> External BGP >> >> >> >> 20 >> >> OSPF >> >> >> >> 110 >> >> IS-IS >> >> >> >> 115 >> >> RIP >> >> >> >> 120 >> >> Internal BGP >> >> >> >> 200 >> >> Unknown >> >> >> >> 255 >> >> Cisco >> >> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html >> <https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html> >> >> *Route Source* >> >> >> >> *Default Distance Values* >> >> Connected interface >> >> >> >> 0 >> >> Static route >> >> >> >> 1 >> >> Enhanced Interior Gateway Routing Protocol (EIGRP) summary route >> >> >> >> 5 >> >> External Border Gateway Protocol (BGP) >> >> >> >> 20 >> >> Internal EIGRP >> >> >> >> 90 >> >> IGRP >> >> >> >> 100 >> >> OSPF >> >> >> >> 110 >> >> Intermediate System-to-Intermediate System (IS-IS) >> >> >> >> 115 >> >> Routing Information Protocol (RIP) >> >> >> >> 120 >> >> Exterior Gateway Protocol (EGP) >> >> >> >> 140 >> >> On Demand Routing (ODR) >> >> >> >> 160 >> >> External EIGRP >> >> >> >> 170 >> >> Internal BGP >> >> >> >> 200 >> >> Unknown* >> >> >> >> 255 >> >> On Thu, Jul 1, 2021 at 2:54 PM Robert Raszuk >> <robert@raszuk.net <mailto:robert@raszuk.net>> wrote: >> >> Gyan, >> >> > My understanding is by default most all implementations >> that I know of for example Cisco & Juniper which have use >> identical default AD >> >> Can you provide source(s) of your above information ? >> >> To the best of my knowledge they are quite different ... >> >> Cisco: >> >> Juniper: >> >> Except connected I do not see much of "identical default AD" >> >> And that is as the draft says especially important when >> your intention is to control active - backup paths for a >> given net. >> >> Thx, >> R. >> >> On Thu, Jul 1, 2021 at 8:02 PM Gyan Mishra >> <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> wrote: >> >> Hi Enke >> >> My understanding is by default most all >> implementations that I know of for example Cisco & >> Juniper which have use identical default AD, >> redistribution of the route only occurs from the >> source protocol that is being redistributed for >> example static versus OSPF or ISIS based on AD. >> >> So if you have multiple protocols redistribution into >> BGP, the source protocol with the lowest AD is what >> is inserted into the default RIB/FIB and its that >> specific route from the source protocol that is >> redistributed into BGP. All implementations that I >> know of work that way. >> >> I don’t see any issue with deterministic >> redistribution as exists today with implementations. >> >> Normally you are only running one IGP but let’s say >> you are running OSPF and ISIS and you have a Juniper >> and Cisco ASBR redistribution into BGP, as OSPF has >> default AD 110, the OSPF prefix would be inserted >> into the Default RIB and redistributed into BGP. >> Let’s say you set AD for ISIS down to 90 and now the >> ISIS route is inserted into the RIB and now both >> Juniper and Cisco ASBR Will redistribute the ISIS >> route into BGP. >> >> I am not seeing the issue that you are trying to solve. >> >> Kind Regards >> >> Gyan >> >> On Wed, Jun 30, 2021 at 3:19 AM Enke Chen >> <enchen@paloaltonetworks.com >> <mailto:enchen@paloaltonetworks.com>> wrote: >> >> Hi, Robert: >> >> 1) Usually the default admin-distance is >> configurable. Having the same admin-distance >> across implementations would certainly make >> things simpler, but that is not required. What >> matters is the local_pref value for the >> redistribute backup route: >> >> local_pref = default_local_pref - delta; >> >> It needs to be in the right order (relatively) >> for the "role" the route is supposed to play. >> >> It's a good question. We will try to clarify it >> in the next revision. >> >> 2) Certainly it would work if we define the >> "delta" (or "local_pref") for the redistributed >> route based on its role (e.g., primary, >> secondary, tertiary). But extra config would be >> needed for specifying the "role". The algorithm >> described in the draft does not require >> additional config other than the existing >> "admin-distance". When more than two paths are >> involved in a multi-vendor environment, the >> admin-distance needs to be carefully assigned in >> order to get the desired local_pref value. >> >> Thanks. -- Enke >> >> On Tue, Jun 29, 2021 at 1:05 PM Robert Raszuk >> <robert@raszuk.net <mailto:robert@raszuk.net>> wrote: >> >> Hi Enke, >> >> How do you assure that admin distance is the >> same or delta would be the same across >> implementations ? >> >> Looking at say junos I see quite different >> values then when comparing with other >> implementations ... >> >> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Ddefault-2Droute-2Dpreference-2Dvalues.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=GOhXjwEf1z0GAfIQVgVAc4sHvcAog6czTO30VhKwzQk&e=> >> >> Would it be simpler to define here verbatim >> what the local pref should be for >> redistributed routes ? Then at least those >> could be used as default local pref values >> unless overwritten by operator's policy >> during redistribution. >> >> Thx, >> Robert >> >> On Tue, Jun 29, 2021 at 7:14 PM Enke Chen >> <enchen@paloaltonetworks.com >> <mailto:enchen@paloaltonetworks.com>> wrote: >> >> Hi, Folks: >> >> Apologies for the very long delay in >> updating the draft: >> >> https://datatracker.ietf.org/doc/draft-chen-bgp-redist/01/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchen-2Dbgp-2Dredist_01_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=IBn3kTJmGrWISvSq8L3M9GLLamXIqw7t2PvEdtvhmos&e=> >> >> The issue still exists, and shows up from >> time to time. The revised version >> provides a complete solution that covers >> the use cases involving a single router >> as well as multiple routers in a network. >> >> Your review and comments are welcome. >> >> Thanks. -- Enke >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org <mailto:Idr@ietf.org> >> https://www.ietf.org/mailman/listinfo/idr >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=O1wpTf7XmDmE4-mQGDJ9YNEx2UVZW-k1meY3fd-tQrE&e=> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org <mailto:Idr@ietf.org> >> https://www.ietf.org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr> >> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> /Network Solutions Architect / >> >> /Email gyan.s.mishra@verizon.com >> <mailto:gyan.s.mishra@verizon.com>/ >> >> /M 301 502-1347/ >> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> /Network Solutions Architect / >> >> /Email gyan.s.mishra@verizon.com >> <mailto:gyan.s.mishra@verizon.com>/ >> >> /M 301 502-1347/ >> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> /Network Solutions Architect / >> >> /Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>/ >> >> /M 301 502-1347/ >> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> /Network Solutions Architect / >> >> /Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>/ >> >> /M 301 502-1347/ >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt Brian Dickson
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt UTTARO, JAMES
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Jakob Heitz (jheitz)
- Re: [Idr] draft-chen-bgp-redist-01.txt Gert Doering
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt tom petch
- Re: [Idr] draft-chen-bgp-redist-01.txt Jakob Heitz (jheitz)
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Jakob Heitz (jheitz)
- Re: [Idr] draft-chen-bgp-redist-01.txt Alejandro Acosta
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Robert Raszuk
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Alejandro Acosta
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Gyan Mishra
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Enke Chen
- Re: [Idr] draft-chen-bgp-redist-01.txt Alejandro Acosta
- Re: [Idr] draft-chen-bgp-redist-01.txt tom petch
- Re: [Idr] draft-chen-bgp-redist-01.txt Jeffrey Haas