Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 5 Jul 2017 22:54:08 +0000

Jeff, John,

I didn’t see the latest -03 addressing the below. Any plans?

--
Cheers,
Rajiv

From: Rajiv Asati <[email-masked]>
Date: Sunday, April 16, 2017 at 3:42 PM
To: Jeffrey Haas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

Hi Jeff,

   But more importantly, you'll stop sending it toward your own peering and
   attracting blackholed traffic.
Indeed. That’s key.

And it could rely on the route resolvability condition to be appropriately modified, as described in
https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria.

    RS-BFD basically reinvents the same procedure in your draft, simply being
    specific about the use of BFD as the dataplane liveness check mechanism.
    However, as you note in the RS-BFD draft, we do leave the option for other
    mechanisms.

    I suspect the other authors of RS-BFD aren't particular where we pick up our
    text for the resolvability condition.  However, if the suggestion is to make
   a reference to your draft, you'll need to bring it back from zombie state
    and progress it. :-)

Agreed. It is alive (-07 version). https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria-07
It can be used as a normative reference in your draft.

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 14, 2017 at 5:36 PM
To: Rajiv Asati <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

    Rajiv,

    On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote:
    > Is the assumption here that the client routers have routing view limited to what’s provided by the Route Server? If not, then wouldn’t Client Routers benefit from having to invalidate the path learned from the remote client router as soon as the connectivity check failed?

    This is what I believe the procedure says.  See section 6.

    > Of course, Client Routers conveying the lack of NLRI reachability per NH to the Route Server, and expecting Route Server to provide a different NHs of the NLRIs, and expecting it to be functional, while still attracting the traffic for unreachable destinations since the Loc-RIB is still pointing to the unreachable NH for the affected NLRIs.

    The thing that is somewhat different for a IXP environment running a route
    server than normal eBGP is the low (to zero) likelihood of having a backup
    path.  If 10/8 was learned from the route server for nexthop 192.0.2.1, and
    you stop being able to reach that nexthop, removing it from your forwarding
    (unreachable) is your only choice.

    You *might* have a source of that path internally.  In that case, you can
    use it.

    But more importantly, you'll stop sending it toward your own peering and
    attracting blackholed traffic.

    > I wonder whether  https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria be useful here.

    In a sense of good timing, John Scudder had brought this to my attention
    about an hour ago.

    RS-BFD basically reinvents the same procedure in your draft, simply being
    specific about the use of BFD as the dataplane liveness check mechanism.
    However, as you note in the RS-BFD draft, we do leave the option for other
    mechanisms.

    I suspect the other authors of RS-BFD aren't particular where we pick up our
    text for the resolvability condition.  However, if the suggestion is to make
    a reference to your draft, you'll need to bring it back from zombie state
    and progress it. :-)

    -- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 18 Jul 2017 11:24:37 +0200

Hi Rajiv,

In reviewing draft-ietf-idr-bgp-bestpath-selection-criteria-07, I note section 3 has:

   The mechanism(s) to perform the "path availability" check and the
   selection of particular data plane are a matter of a policy and
   outside the scope of this document.

RS-BFD represents an instance of a specific path availability check and selection of data plane. Based on that, it seems to me the RS-BFD could add something like the following in the introduction:

   [I-D.ietf-idr-bgp-bestpath-selection-criteria] discusses enhancement
   of the route resolvability condition of section 9.1.2.1 of [RFC4271]
   to include next hop reachability and path availability checks.  This
   specification represents in part an instance of such, implemented
   using BFD as the OAM mechanism.

If you have other suggestions for text, please send them.

Thanks,

--John

> On Jul 6, 2017, at 12:54 AM, Rajiv Asati (rajiva) <[email-masked]> wrote:
> 
> Jeff, John,
>  
> From: Jeffrey Haas <[email-masked]>
> To: Rajiv Asati <[email-masked]>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 20 Jul 2017 00:42:44 +0000

Hi John,

The suggested text seems reasonable. 

I will glance through the draft to see if any other section needs updating in lieu of this change.

-- 
Cheers,
Rajiv  

-----Original Message-----
From: John Scudder <[email-masked]>
Date: Tuesday, July 18, 2017 at 5:24 AM
To: Rajiv Asati <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

    Hi Rajiv,

    

    
    Thanks,
    
    --John