Re: [mpls] I-D Action: draft-ietf-mpls-egress-protection-framework-02.txt

[Yimin Shen <[e-mail]>]

Hi James,

Thanks for your questions and comments.

[QUERY1]

This framework focuses on provider’s MPLS networks, and the goal is to make sure that traffic be fast-rerouted towards a service destination. It does not go beyond egress routers/links to a CE domain to make any suggestion there. That is out of the scope of this draft. If there is any local policy on a CE which may cause the CE to reject the rerouted traffic coming over the backup link/path, it should be adjusted and resolved locally (on the CE or in the CE domain) to align with the protection schema. In any case, this should not affect how egress protection should work in the provider’s MPLS network.

In your specific example, you have an RPF policy for an IP service on the CE. When provisioning the CE, the user should be aware of the existence of the backup link/path, and should understand what to anticipate over the backup link/path. Hence, a solution to consider both rerouted traffic and security should be possible. In fact, you will have the same issue regardless the kind of protection/restoration mechanism in the MPLS network, whether it is egress protection, global repair driven by ingress router, or control protocol convergence. In any of these cases, if your CE is slower than the reaction of the MPLS network, you will have the same issue.

[QUERY2]

Yes, it should be PE2. Thanks for catching this. We will fix it in the final version.

[QUERY1]

This text talks strictly about how PE3 should construct nexthops for the routes in the protection VRF (not the normal VRF). The text does not suggest or imply any change to the PE3’s BGP advertisement towards other routers. There should not be any confusion here.

Hope the above has clarified for you.

Thanks,

-- Yimin


On 7/23/18, 4:52 PM, "mpls on behalf of James Bensley" <[e-mail] on behalf of [e-mail]> wrote:

    Hi All,
    
    I hope this is the correct place to ask these questions, I'm new to
    the IETF WG processes so please guide me if you can. I've read the
    draft and have some feedback/queries.
    
    [QUERY1]
    In the section 1.Introduction:
    "Local repair refers to the scenario where the router upstream to an
    anticipated failure (aka. PLR, i.e. point of local repair)
    pre-establishes a bypass tunnel to the router downstream of the
    failure (aka. MP, i.e. merge point), pre-installs the forwarding state
    of the bypass tunnel in the data plane, and uses a rapid mechanism
    (e.g. link layer OAM, BFD, and others) to locally detect the failure
    in the data plane. When the failure occurs, the PLR reroutes traffic
    through the bypass tunnel to the MP, allowing the traffic to continue
    to flow to the tunnel's egress router."
    ....
    "This framework requires that the destination (a CE or site) of a
    service MUST be dual-homed or have dual paths to an MPLS network, via
    two MPLS edge routers."
    
    The first text quoted above seems generic enough that it can apply to
    both an egress node or egress link failure. With egress node failure
    the the requirement for a Merge Point and fast failure detection
    mechanism equate to a backup egress node and/or protector node
    (depending on whether centralized or co-located mode is being used)
    and OAM, BFD, LoS etc. In the case of an egress link failure though,
    as per the 2nd text quoted above, the CE must be dual homed to the
    network and then the PLR is the egress node. The first text quoted
    above indicates that the PLR must have a rapid failure detection
    mechanism but it is not stipulated that the CE must also detect the
    failure as quickly as the egress node.
    
    It does say under section 6. Egress link protection:
    "However, protection for ingress link failure SHOULD be provided by a
    separate mechanism, and hence is out of the scope of this document."
    
    However, there are two problems that I can see;
    
    1. If the CE hasn't detected the PE-CE link is down as fast as the PE,
    traffic from the MPLS network towards the CE will be rerouted via the
    backup path (backup PE-CE link via backup egress node) but the return
    traffic from CE to MPLS network will be sent over the PE-CE link
    towards egress node and not the backup egress node, which means that
    traffic will be black-holed until the CE realises it's primary link is
    down.
    
    2. If the CE uses uRPF it should drop the traffic coming from the
    PE-CE link from the backup egress node until it detects the PE-CE link
    to the egress node is down.
    
    Both of these scenarios are based on the assumption that the PE to CE
    links are in active/passive or primary/secondary depending on your
    terminology - only one link is being used, the other is purely a
    backup for when the first is down. However, active/passive links to
    dual-homes CEs is extremely common and the fast re-route mechanism
    being offered by this draft can be completely undermined because of
    the two reasons I have outlined above.
    
    To prevent the draft be undermined like this:
    
    - Opt1. I think it is worth either mentioning the issues that can
    arise if the CE doesn't detect the issue with the PE-CE link as
    quickly as the PE.
    - Opt2. Alternatively, I think it is worth mentioning something like
    "the CE SHOULD detect the PE-CE link down as quickly as the PE" - a
    statement which is fairly vague but prevents the entire
    feature/technology in the draft being undermined when it is correctly
    implemented.
    - Opt3. Another alternative, is to suggest that "the PE-CE link SHOULD
    run a fast failure detection mechanism (the exact choice is outside
    the scope of this document)" and recommend the implementer use a fast
    failure detection mechanism between the PE and CE as it's not clearly
    called out anywhere as far as I can see, only within the MPLS core
    between PE or P nodes.
    - Opt4. Something else?
    
    Further to this - should the draft make a statement about the use of
    all-active or active/passive links? In the case of all active links
    (e.g. ECMP) the uRPF issue no longer exists.
    
    
    [QUERY2]
    >From section 8.2. Egress link protection:
    "When PE3 detects a failure of the egress link, it will invoke the
    above bypass nexthop to reroute VPN service packets."
    
    Is that a typo and should be PE2?
    
    
    [QUERY3]
    >From section 8. Example: Layer-3 VPN egress protection:
    "The nexthops of these routes MUST be based on PE3's connectivity with
    site 2, even if this connectivity is not the best path in PE3's VRF
    due to metrics (e.g. MED, local preference, etc.), and MUST NOT use
    any path traversing PE2."
    
    PE3 is never going to advertise its (presumably) less preferred path
    to site 2's prefixes towards PE2 because it is receiving more
    preferred paths from PE2. This draft isn't clearly saying if this
    behaviour will be overridden ONLY for MPLS VPNs that have this egress
    protection mechanism explicitly configured or if it relies on the PE
    already having something like "BGP Advertise Best-External" in Cisco
    speak or what I think is called "Provider Edge Link Protection" in
    Junos speak, already enabled. Should this be clearly stated in the
    draft?
    
    
    Kind regards,
    James.
    
    _______________________________________________
    mpls mailing list
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=oYbfCFZBkqt0fPILE48NoX_4F6MoGf0FPy73BeOwU5M&s=Z4QrqAKMgN3utKrl2oomIpmJRNrUxazXy2GmDtgWpFI&e=