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, 3 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>rg>; 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