Subject: Re: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft

From: Curtis Villamizar <[email-masked]>
Date: Tue, 21 Jul 2009 22:08:35 -0400

Susan Hares wrote:
> We have received a request to accept draft-asati-idr-bgp-bestpath-selection-criteria-00.txt as an IDR WG document. Please send your votes by 8/3/09. 
> Sue and John 

The draft that I just fetched (as -01) says:

    This Internet-Draft,
    draft-asati-idr-bgp-bestpath-selection-criteria-00.txt, has
    expired, and has been deleted from the Internet-Drafts directory.

I'm not sure how we can take a "vote" with the draft unavailable for
review.

Curtis

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 21 Jul 2009 22:57:23 -0400

On Jul 21, 2009, at 10:08 PM, Curtis Villamizar wrote:
> Susan Hares wrote:
>> We have received a request to accept draft-asati-idr-bgp-bestpath- 
>> selection-criteria-00.txt as an IDR WG document. Please send your  
>> votes by 8/3/09.
>> Sue and John
>
>

A fair point.

Rajiv, can you please refresh the draft?

Curtis, my advanced search engine skills enabled me to find http://tools.ietf.org/html/draft-asati-idr-bgp-bestpath-selection-criteria-00 
  , which should take care of the practical issue if you don't want to  
wait until the draft gets refreshed (which I assume will only happen  
after the IETF due to the pre-IETF draft publication freeze).

--John

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 Jul 2009 23:48:10 -0400

Hi John,

> Curtis, my advanced search engine skills enabled me to find
>
http://tools.ietf.org/html/draft-asati-idr-bgp-bestpath-selection-criter
ia-00

> after the IETF due to the pre-IETF draft publication freeze).

Indeed. We will have to wait until the 27th (one more week) per the
publication freeze. 
I have the next version ready to go.

Thanks for sharing the pointer to the -00 draft.

Cheers,
Rajiv

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Tuesday, July 21, 2009 10:57 PM
> To: [email-masked]; Rajiv Asati (rajiva)
> Cc: idr List
> Subject: Re: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria as
IDR WG
> draft
> Curtis, my advanced search engine skills enabled me to find
>
http://tools.ietf.org/html/draft-asati-idr-bgp-bestpath-selection-criter
ia-00

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 23 Jul 2009 00:22:42 -0400

In message <[email-masked]>
> after the IETF due to the pre-IETF draft publication freeze).

Fair enough.  You're a wizard with that there searchie thingie.

The first rule just seems obvious and out of scope for RFC4271.  Is
the first rule saying much more than "If there is more than one IGP
instance, pick the right one"?  If so is that too obvious to need to
be stated?

The second rule is a "ping the next hop" rule, or more correctly check
the OAM status.

It strikes me that if we did the analogous thing for BGP and IP
routers, we'd be suggesting that a ping of the next hop be performed
just in case a router along the way wasn't working correctly (which in
the very early 1990s was a distinct possibility, but I digress).  The
"right answer" for IP then was to make sure IP routers really do work
at the IP/IGP level, and not triggerred by a BGP prefix reference to a
particular next hop.

Based on the examples, it looks like the problemm areas are in L3VPN
using MPLS and LDP.  But what if the BGP router is one more hop back
in the IGP on the left CE side of the diagrams?  If so it may not be
aware of the MPLS LSP.  Do things break then?

Are providers really serving up broken L2TP, GRE, or L3 VPNs and if so
is this the right venue to be addressing the problem?  Are we better
off working around this sort of brokenness in BGP or fixing it in the
underlying offender (L2TP, GRE, or L3 VPNs, or more correctly
someone's broken implementation of them)?

Curtis

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2009 00:13:11 -0700

Hi Curtis,

I think your assessment of the draft is right. The original issue has 
been raised by the problem of considering next hop as valid and 
reachable IP reachability wise without any correlation with MPLS LSP to 
such next hop which was a must and a prerequisite for some applications 
to work.

In my opinion this is a valid problem, but this is not a BGP issue.

Underlying transport (for example MPLS LDP or MPLS-TE) should only 
expose valid and reachable LSPs to it's RIB so when BGP does route 
validation and resolution it would already be able to choose from valid 
and reachable next hops. That would result in no changes to BGP both 
protocol and implementation wise.

So I would recommend to move this draft to mpls wg as essentially only 
this transport exhibits the problem described in the spec.

Cheers,
R.

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: <[email-masked]>
Date: Thu, 23 Jul 2009 11:37:48 +0200

Hi Rajiv, all,

Following Robert's comment regarding MPLS (wg) dependency, in the
section 2 "Route Resolvability Condition - Modification" what about
adding the following point between 1) (use the right NH availability
info) and 2) (use OAM to check):

SHOULD use LDP ordered mode (rather than independent) to check the end
to end control plane status.
(then forwarding plane status may optionally be checked by the "OAM
data-plane liveness mechanisms" that you currently propose in 2) )

Thanks,
Regards,
Bruno

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 23 Jul 2009 12:08:01 +0200

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Robert Raszuk
> Gesendet: Donnerstag, 23. Juli 2009 09:13
> An: [email-masked]
> Cc: idr List
> Betreff: Re: [Idr] 
> draft-asati-idr-bgp-bestpath-selection-criteria as IDR WG draft
> 
> Hi Curtis,
> 
> I think your assessment of the draft is right. The original 
> issue has been raised by the problem of considering next hop 
> as valid and reachable IP reachability wise without any 
> correlation with MPLS LSP to such next hop which was a must 
> and a prerequisite for some applications to work.
> 
> Underlying transport (for example MPLS LDP or MPLS-TE) should 
> only expose valid and reachable LSPs to it's RIB so when BGP 

Robert,

in some scenarios (e.g Inter-AS MPLS stuff) labels are distributed by BGP itself. Also, LDP may have received all correct info from the neighbors, but failed to install it into forwarding plane (either due to hardware failure or a software bug). Having experienced this with routers from two different manufacturers, I believe it would be really benefical if BGP could perform a bit more extended checks rather than just looking into control plane. I understand that issue is more of "local type" (e.g. hardware failure) rather than protocol itself, but considering reality (bugs do happen and hardware does fail) it's very desirable that BGP specs at least encourage implementors to make more effort in validating next-hop. And this is why I believe IDR is correct WG for this draft.

Cheers,
iLya

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2009 03:45:50 -0700

Ilya,

Are you really recommending that each application (one of them being 
BGP) which may use underlying transport of LSPs to continuously perform 
it's own OAM check over such LSPs ?

I really think it is a data plane OAM thing which should be done in full 
abstraction to routing protocols or label distribution protocols before 
such LSP is inserted in RIB as a means to reach destination XYZ.

Cheers,
R.

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 23 Jul 2009 14:01:45 +0200

> BGP) which may use underlying transport of LSPs to 
> continuously perform it's own OAM check over such LSPs ?
> 

Not exactly. There are two things BGP could potentially do: 

- first it could consult local forwarding plane to check whether next-hop info has been installed there.

- second, in some cases BGP could rely on OAM (e.g. BFD) for verifying next-hop availability. It may sound as not very scaleable, it could be used for example to check availability of critical exit points such as major IXP or uplinks. 

Cheers,
iLya

---

From: Mike Benjamin <[email-masked]>
Date: Thu, 23 Jul 2009 09:51:32 -0700

On Thu, Jul 23, 2009 at 12:22:42AM -0400, Curtis Villamizar wrote:
: 
: The first rule just seems obvious and out of scope for RFC4271.  Is
: the first rule saying much more than "If there is more than one IGP
: instance, pick the right one"?  If so is that too obvious to need to
: be stated?

The first rule is stating that if the nexthop lookup resolves to a
path that has no knowledge of the route, it should not be considered.

For example, two LERs that do not exchange their BGP table with the
LSR.  In the event of an LSP failure, BGP still resolves the nexthop,
via an IGP path, installs the route, and the device blackholes
anything destined for it.

The mechanism is stating that BGP should be given the knowledge of
where to look for a valid nexthop.  IGP sourced RIB entries can be
considered to establish the BGP session, but should not be used to
resolve the nexthop if that path has no knowledge of how to get there.

--mikeb

: 
: Curtis
: _______________________________________________
: Idr mailing list
: [email-masked]
: https://www.ietf.org/mailman/listinfo/idr

--
Mike Benjamin   -     +1-602-744-3403
[email-masked]  - Development Engineering
Global Crossing -       Phoenix, USA

---

From: Mike Benjamin <[email-masked]>
Date: Thu, 23 Jul 2009 10:16:56 -0700

On Thu, Jul 23, 2009 at 12:13:11AM -0700, Robert Raszuk wrote:
: 
: I think your assessment of the draft is right. The original issue 
: has been raised by the problem of considering next hop as valid 
: and reachable IP reachability wise without any correlation with 
: MPLS LSP to such next hop which was a must and a prerequisite for 
: some applications to work.
: 
: In my opinion this is a valid problem, but this is not a BGP 
: issue.
: 
: Underlying transport (for example MPLS LDP or MPLS-TE) should 
: only expose valid and reachable LSPs to it's RIB so when BGP does 
: route validation and resolution it would already be able to 
: choose from valid and reachable next hops. That would result in 
: no changes to BGP both protocol and implementation wise.

Only exposing valid and reachable LSPs to the RIB would push the
OAM aspect of problem #2 back to MPLS if you are using RSVP-TE or
LDP for label exchange.  As Ilya has pointed out, BGP is also used
for label exchange, meaning you've also pushed the requirement to
BGP.

Issue #1 also still exists due to the IGP presenting the route.  The
"fix" currently would be to not use IGP learned addresses for BGP
peering.  This means things like static routes tied to LSPs that
don't seem like the correct answer to me.

The scenario that presents this problem is not isolated to L3VPNs.
A network that uses IGP only for control plane in order to establish;
BGP for route exchange, and another protocol for transport
(MPLS/L2TP/etc..), also presents the problem.  In such a network
design, informing BGP that that only the transport protocol installed
routes may be used to resolve nexthops would be required.

--mikeb

: So I would recommend to move this draft to mpls wg as essentially 
: only this transport exhibits the problem described in the spec.
: 
: Cheers,
: R.
: 
: 
: >Fair enough.  You're a wizard with that there searchie thingie.
: >
: >The first rule just seems obvious and out of scope for RFC4271.  
: >Is
: >the first rule saying much more than "If there is more than one 
: >IGP
: >instance, pick the right one"?  If so is that too obvious to 
: >need to
: >be stated?
: >
: >The second rule is a "ping the next hop" rule, or more correctly 
: >check
: >the OAM status.
: >
: >It strikes me that if we did the analogous thing for BGP and IP
: >routers, we'd be suggesting that a ping of the next hop be 
: >performed
: >just in case a router along the way wasn't working correctly 
: >(which in
: >the very early 1990s was a distinct possibility, but I digress). 
: >The
: >"right answer" for IP then was to make sure IP routers really do 
: >work
: >at the IP/IGP level, and not triggerred by a BGP prefix 
: >reference to a
: >particular next hop.
: >
: >Based on the examples, it looks like the problemm areas are in 
: >L3VPN
: >using MPLS and LDP.  But what if the BGP router is one more hop 
: >back
: >in the IGP on the left CE side of the diagrams?  If so it may 
: >not be
: >aware of the MPLS LSP.  Do things break then?
: >
: >Are providers really serving up broken L2TP, GRE, or L3 VPNs and 
: >if so
: >is this the right venue to be addressing the problem?  Are we 
: >better
: >off working around this sort of brokenness in BGP or fixing it 
: >in the
: >underlying offender (L2TP, GRE, or L3 VPNs, or more correctly
: >someone's broken implementation of them)?
: >
: >Curtis
: >_______________________________________________
: >Idr mailing list
: >[email-masked]
: >https://www.ietf.org/mailman/listinfo/idr
: >
: 
: _______________________________________________
: Idr mailing list
: [email-masked]
: https://www.ietf.org/mailman/listinfo/idr