Re: [Idr] draft-chen-bgp-redist-01.txt

[Alejandro Acosta <[e-mail]>]

Hello Enke,

   You are totally right, the prefix could have more than one ROA, 
perfectly valid. Easy and straight forward solution.


Alejandro,


On 3/7/21 6:42 PM, Enke Chen wrote:
> Hi, Alejandro:
>
> If I understand correctly, what you have described is a routing 
> scenario for a multi-homed customer involving multiple AS'es. It's 
> different from the one described in the draft.
>
> In your description, the prefix can be legitimately sourced by more 
> than one AS. Thus it should be registered with multiple AS origins.
>
> Thanks.   -- Enke
>
> On Sat, Jul 3, 2021 at 6:22 AM Alejandro Acosta 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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 <[e-mail]> <mailto:[e-mail]>
>>>     *On Behalf Of * Gyan Mishra
>>>     *Sent:* Thursday, July 1, 2021 6:18 PM
>>>     *To:* Robert Raszuk <[e-mail]> <mailto:[e-mail]>
>>>     *Cc:* idr@ietf. org <[e-mail]> <mailto:[e-mail]>; Jenny
>>>     Yuan <[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *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
>>>     <[e-mail] <mailto:[e-mail]>> 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
>>>         <[e-mail] <mailto:[e-mail]>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junose15.1_topics_task_configuration_ip-2Droute-2Dadministrative-2Ddistance-2Dconfiguration.html&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=735ipugi7SGesVlY0SEFmSNpYqTCsecAg_O1SMKNSOQ&e=>
>>>
>>>             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://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_15986-2Dadmin-2Ddistance.html&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=V01amfitHyWGAZGUhzoFgDiAai3FDMero5ckZo5B26Q&e=>
>>>
>>>             *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
>>>             <[e-mail] <mailto:[e-mail]>> 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
>>>                 <[e-mail]
>>>                 <mailto:[e-mail]>> 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
>>>                     <[e-mail]
>>>                     <mailto:[e-mail]>> 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 <[e-mail]
>>>                         <mailto:[e-mail]>> 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 <[e-mail]
>>>                             <mailto:[e-mail]>> 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
>>>                                 [e-mail] <mailto:[e-mail]>
>>>                                 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
>>>                         [e-mail] <mailto:[e-mail]>
>>>                         https://www.ietf.org/mailman/listinfo/idr
>>>                         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>>>
>>>                     -- 
>>>
>>>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>>>
>>>                     *Gyan Mishra*
>>>
>>>                     /Network Solutions Architect /
>>>
>>>                     /Email [e-mail]
>>>                     <mailto:[e-mail]>/
>>>
>>>                     /M 301 502-1347/
>>>
>>>             -- 
>>>
>>>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>>>
>>>             *Gyan Mishra*
>>>
>>>             /Network Solutions Architect /
>>>
>>>             /Email [e-mail]
>>>             <mailto:[e-mail]>/
>>>
>>>             /M 301 502-1347/
>>>
>>>         -- 
>>>
>>>         <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>>>
>>>         *Gyan Mishra*
>>>
>>>         /Network Solutions Architect /
>>>
>>>         /Email [e-mail]
>>>         <mailto:[e-mail]>/
>>>
>>>         /M 301 502-1347/
>>>
>>>     -- 
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>>>
>>>     *Gyan Mishra*
>>>
>>>     /Network Solutions Architect /
>>>
>>>     /Email [e-mail] <mailto:[e-mail]>/
>>>
>>>     /M 301 502-1347/
>>>
>>>
>>>     _______________________________________________
>>>     Idr mailing list
>>>     [e-mail]  <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/idr  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>     _______________________________________________
>     Idr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>
>