Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 4 May 2020 18:10:10 +0000

Thanks, Alvaro. While it would have been preferred to keep the (NH selection / verification) logic independent, it seems that there may perhaps be the following 2 means to solidify the logic -
 
 a- Tunnel Encapsulation Attribute (updating rfc5512)
 b- Cost Community
 
It seems that (a) is somewhat more progressive than (b), and clearly conveys the encap preference that can be leveraged. Thoughts?

If agreed, then section 3 could be updated to reflect something akin to the following -

//
1)	Next-hop resolution SHOULD check for NLRI’s next-hop address in a routing/forwarding database related to a particular data plane protocol, if it is signaled by BGP Tunnel encapsulation attribute [T-ENCAP]. If the check does NOT succeed, then NLRI path can be marked as 'next-hop route inaccessible'.

It is also possible for a policy to override the default behavior. Such a policy may be applied either per next-hop or per AFI/SAFI or both, however, it is deemed out-of-scope for this document.  

This check is about confirming the availability of valid entry for the next-hop address in the forwarding database related to the data plane protocol.

2)	The next-hop resolution MAY check for the entire path to the next-hop being functional or not, in a database related to a particular data plane protocol, if it is signaled by BGP Tunnel encapsulation attribute [T-ENCAP]. If the check does NOT succeed, then NLRI path can be marked as 'next-hop path inaccessible'.

Selection of a particular mechanism and data plane protocol are a matter of a policy and is outside the scope of this document. If policy is not supplied, then the default behavior is to not perform this check.

This check is about confirming the availability of valid entry for the next-hop address in the forwarding database related to the data plane protocol.
//

Would appreciate any feedback you may have.

-- 
Cheers,
Rajiv Asati
vCTO/Distinguished Engineer, CX CTO Office

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Date: Thursday, January 9, 2020 at 3:44 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
Resent-From: <[email-masked]>
Resent-To: Rajiv Asati <[email-masked]>
Resent-Date: Thursday, January 9, 2020 at 3:43 PM

    Dear Chairs/WG:

    Happy New Year!

    I am returning this document to the WG for further discussion.

    Rajiv, Sue and I had a very fruitful conversation while in Singapore
    at the last IETF.  We agree on the technical issues, but (as explained
    in my review -- I left the header below [*]) my concerns go beyond the
    content and into the Status of the document and the general interest
    from the WG in this work.

    Sue/John:  I need you to explicitly collect feedback from the WG and
    reevaluate support for the document's content and status.
    Specifically, we need a *discussion* about the first two points
    mentioned below.

    Thank you!!

    Alvaro.

    [*] The full review is here:
    https://mailarchive.ietf.org/arch/msg/idr/85qTCgN4k6oAbSlKmpyi8stxZz0

    On July 17, 2019 at 4:15:57 PM, Alvaro Retana wrote:

    > Rajiv:
    >
    > Hi! How are you? I just finished reading this document.
    >
    > First of all, thank you for your patience and perseverance in sticking with
    > this document for so long!
    >
    > Having said that, I have significant issues with the document. I have
    > specific in-line comments below, but I want to highlight some of the bigger
    > issues now -- please note that while you are the Author, the issues called
    > out here are directed at the WG/Chairs/Shepherd as well.
    >
    > (1) What is the Update to rfc4271?
    >
    > The document presents two amendments to the Route Resolvability Condition
    > (§9.1.2.1/rfc4271). The first one is straight forward and obvious: resolve
    > the next-hop using the correct Routing Table.
    >
    > The second one is to check the "path availability" to the next-hop. While a
    > good thing to do, and optional, it introduces in the BGP Decision Process
    > unspecified functionality that depends on external mechanisms...which, in my
    > opinion, should be used to maintain the Routing Table and not be specifically
    > a part of BGP.
    >
    > Both the policy to drive Amendment 1 and the expectations of the check in
    > Amendment 2 are not specified and declared out of scope. IOW, the
    > specification is to do something that is not specified. Back to my question:
    > what is the Update to rfc4271?
    >
    > I didn't find a discussion on the list about the Update: either about
    > formally Updating rfc4271, *or* what the Update would be. I did find a note
    > [1] that says "our AD requested we move the document from Informational to
    > Standards track, and add 'Updates: RFC 4271'"...but there was no discussion;
    > in fact, no reply at all.
    >
    > [Disclaimer: I was not the AD in 2011.]
    >
    > Related to this point, and specifically to the "path availability"
    > functionality... In the Implementation Report [2], one of the implementers
    > reports support for "path availability check in several variations, but not
    > all. For example, BFD may be used to protect MPLS generated nexthops for LDP
    > and RSVP. For IP nexthops distributed via an IGP, the IGP may be protected
    > using BFD." Because the "path availability" functionality is not specified in
    > this document, then I'm not sure whether either of these satisfies this
    > document...but both mechanisms described are about protecting the next-hops
    > (and presumably triggering FRR, for example), and not specifically about
    > providing BGP with an indication of availability to forward traffic (which is
    > my interpretation of "path availability").
    >
    > To be clear: I mention this text from the Implementation Report not to
    > criticize the implementation...but to support the points that (1) the
    > specification in this document is incomplete, and (2) that the OAM mechanisms
    > should be used to maintain the Routing Table (and not just interact directly
    > with BGP). IOW, I believe that the implementation is doing the right
    > thing...but that is not what is described in the document.
    >
    > [See more related comments in §3, after Amendment 2.]
    >
    >
    > (2) WG Discussion (...or lack of...)
    >
    > As I mentioned above, there was no discussion of the Update in the WG. In
    > fact, the only significant discussion was during adoption [3] -- at that
    > point the draft was Informational and it didn't Update anything.
    >
    > The WGLCs [4][5] show only 1 comment, and no other explicit show of support.
    > Not even the usual "support...+1...+1...".
    >
    > I went back and looked at the minutes from IETF 73 [6], which is where the
    > draft was presented for the first time, but there was no feedback there.
    >
    > draft-asati-bgp-mpls-blackhole-avoidance, which was presented at IETF 68, was
    > the precursor of this document. The minutes from that meeting [7] show not a
    > lot of excitement and minor support for perhaps an Informational one-page
    > document saying "please be careful about selecting a next hop".
    >
    > One last note on this point. The Shepherd's writeup [8] reads:
    >
    >    (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?
    >
    >    Solid in 2009. As time goes on waiting for implementation reports,
    >    the memory of those days weakens. However, since 2 major vendors
    >    have implemented and deployed this RFC - the solid WG
    >    support from 2009 has been validated.
    >
    > The draft was adopted with rough consensus [3], so I don't interpret
    > implementations in this case as strong validation mainly because I don't see
    > a clear specification.
    >
    > All this leads me to ask: Is this work (many years later!) still something
    > the WG wants to progress? Or has it been taken over by events? Is the
    > document in it's current form what the WG thought it was adopting?
    >
    > I am looking for discussion and specific opinions (not +1s!). I would be very
    > happy if someone pointed me to discussions I missed in my search.
    >
    >
    > (3) Terminology
    >
    > In general, I think that most idr participants would clearly understand the
    > terminology used in this document. However, the audience is wider than that,
    > and the terminology used doesn't correspond to that in other work.
    >
    > For example, the first sentence in the Abstract reads:
    >
    >    BGP specification (RFC4271) prescribes 'BGP next-hop reachability'
    >    as one of the key 'Route Resolvability Condition' that must be
    >    satisfied before the BGP bestpath candidate selection.
    >
    > rfc4271 doesn't talk anywhere about reachability or a bestpath.
    >
    > Please be consistent with the terminology in other RFCs, specially rfc4271.
    > Introducing new terms is fine, if they are needed and properly explained.
    >
    >
    > Given the points above, I am inclined to return this document to the WG for
    > further discussion. I really don't want to do that given its long history, so
    > perhaps we can use some time next week in Montreal to talk face-to-face.
    >
    > Thanks!
    >
    > Alvaro.
    >
    >
    > [1] https://mailarchive.ietf.org/arch/msg/idr/jWNhfTvHbaY3rEk5nTYahS5w6_Q
    > [2] https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria
    > [3] https://mailarchive.ietf.org/arch/msg/idr/Yr9u6V2HKrHEuQLtFw7aDstMPzg
    > [4] https://mailarchive.ietf.org/arch/msg/idr/kiTwL6ApC_k9QFrfhaMA_qC8BcA
    > [5] https://mailarchive.ietf.org/arch/msg/idr/OqsCexPPmtvKjHNJzf4EcpwPhtQ
    > [6] https://mailarchive.ietf.org/arch/msg/idr/OVg6Cfr3EUwIRcQS6cIkwq_dUtI
    > [7] https://mailarchive.ietf.org/arch/msg/idr/lezFHSGaOzvL2h16M883beeHcjI
    > [8] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/shepherdwriteup/

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 4 May 2020 11:43:58 -0700

On May 4, 2020 at 2:10:14 PM, Rajiv Asati (rajiva) wrote:

[Explicitly adding draft-ietf-idr-tunnel-encaps to the distribution.]

Rajiv:

Hi!

> Thanks, Alvaro. While it would have been preferred to keep the (NH selection
> / verification) logic independent, it seems that there may perhaps be the
> following 2 means to solidify the logic -
>
> It seems that (a) is somewhat more progressive than (b), and clearly conveys
> the encap preference that can be leveraged. Thoughts?
>
...

As a matter of fact, §5 of draft-ietf-idr-tunnel-encaps lists

   *  The tunnel is specified in a TLV whose Tunnel Endpoint sub-TLV
      identifies an IP address that is reachable.

...as a condition for the tunnel to be considered feasible.  In my
review of that document [1] I wrote this:

   [major] How is reachability determined?  Where (which table) should
   the address be looked up in?  In the sequence above, the destination
   address of P and the address of the endpoint may be resolvable in
   different tables...

   [BTW, please also take a look at
   draft-ietf-idr-bgp-bestpath-selection-criteria, which I think tries to
   define a related, if not the same, concept.]

I think this is a good time for you and the authors of
draft-ietf-idr-tunnel-encaps to talk.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/S1nyz1sewA_Xqf63W_vz8c4L8Z0/

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 4 May 2020 21:46:55 +0000

Alvaro,

Well pointed. Back in Feb, when I went through the encap draft (recalling the machinery like in the below excerpt) and discussed with Acee, I also realized these two drafts being complementary in that NH verification regard.  

/
   If the Tunnel Endpoint sub-TLV contains an IPv4 or IPv6 address that
   is valid but not reachable,  
/

The question (of yours) we need to answer is what's in scope and what's not. For ex, what OAM protocol is used for reachability determination should be out of scope, but where this check is executed should be. Hoping that we have some active discussion on that.

Keyur, Srihari, Gunter, thoughts?

-- 
Cheers,
Rajiv  

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Date: Monday, May 4, 2020 at 2:44 PM
To: Rajiv Asati <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12
Resent-From: <[email-masked]>
Resent-To: Rajiv Asati <[email-masked]>
Resent-Date: Monday, May 4, 2020 at 2:44 PM

    Rajiv:

    Hi!

    ...

    Thanks!

    Alvaro.