[Idr] draft-uttaro-idr-bgp-persistence-00

[Robert Raszuk <[e-mail]>]

Authors,

Actually when discussing this draft a new concern surfaced which I would 
like to get your answer on.

The draft in section 4.2 says as one of the forwarding rules:

    o  Forwarding to a "stale" route is only used if there are no other
       paths available to that route.  In other words an active path
       always wins regardless of path selection.  "Stale" state is always
       considered to be less preferred when compared with an active path.

In the light of the above rule let's consider a very simple case of dual 
PE attached site of L3VPN service. Two CEs would inject into their IBGP 
mesh routes to the remote destination: one marked as STALE and  one not 
marked at all. (Each CE is connected to different PE and each PE RT 
imports only a single route to a remote hub headquarter to support 
geographic load balancing).

Let me illustrate:

  VPN Customer HUB

    PE3      PE4
         SP
    PE1      PE2
     |        |
     |        |
    CE1      CE2
     |        |
    1|        |10
     |        |
    R1 ------ R2
          1

CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and 
R2-CE2 is 10.

Prefix X is advertised by remote hub in the given VPN such that PE1 vrf 
towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4.

Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is 
up, next hop is in the RIB while data plane is gone. Assume no data 
plane real validation too. /* That is why in my former message I 
suggested that data plane validation would be necessary */.

R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands 
STALE so selects in his forwarding table path via CE2.

R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not 
understand STALE, never was upgraded to support the forwarding rule 
stated above in the draft and chooses X via CE1 (NH metric 2 vs 10).

R1--R2 produce data plane loop as long as STALE paths are present in the 
system. Quite fun to troubleshoot too as the issue of PE3 injecting such 
STALE paths may be on the opposite site of the world.

The issue occurs when some routers within the customer site will be able 
to recognize STALE transitive community and prefer non stale paths in 
their forwarding planes (or BGP planes for that matter) while others 
will not as well as when both stale and non stale paths will be present.

Question 1: How do you prevent forwarding loop in such case ?

Question 2: How do you prevent forwarding loop in the case when customer 
would have backup connectivity to his sites or connectivity via 
different VPN provider yet routers in his site only partially understand 
the STALE community and only partially follow the forwarding rules ?

In general as the rule is about mandating some particular order of path 
forwarding selection what is the mechanism in distributed systems like 
today's routing to be able to achieve any assurance that such rule is 
active and enforced across _all_ routers behind EBGP PE-CE L3VPN 
boundaries in customer sites ?

Best regards,
R.


-------- Original Message --------
Subject: [Idr] draft-uttaro-idr-bgp-persistence-00
Date: Sat, 22 Oct 2011 00:23:55 +0200
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
To: [e-mail] List <[e-mail]>

Hi,

I have read the draft and have one question and one observation.

Question:

What is the point of defining DO_NOT_PERSIST community ? In other words
why not having PERSIST community set would not mean the same as having
path marked with DO_NOT_PERSIST.

Observation:

I found the below statement in section 4.2:

    o  Forwarding must ensure that the Next Hop to a "stale" route is
       viable.

Of course I agree. But since we stating obvious in the forwarding
section I think it would be good to explicitly also state this in the
best path selection that next hop to STALE best path must be valid.

However sessions especially those between loopbacks do not go down for
no reason. Most likely there is network problem which may have caused
those sessions to go down. It is therefor likely that LDP session went
also down between any of the LSRs in the data path and that in spite of
having the paths in BGP and next hops in IGP the LSP required for both
quoted L2/L3VPN applications is broken. That may particularly happen
when network chooses to use independent control mode for label allocation.

I would suggest to at least add the recommendation statement to the
document that during best path selection especially for stale paths a
validity of required forwarding paradigm to next hop of stale paths
should be verified.

For example using techniques as described in:
draft-ietf-idr-bgp-bestpath-selection-criteria

Best regards,
R.


_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr