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

From: [email-masked]
Date: Thu, 19 Jul 2018 14:43:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching WG of the IETF.

        Title           : MPLS Egress Protection Framework
        Authors         : Yimin Shen
                          Minto Jeyananth
                          Bruno Decraene
                          Hannes Gredler
                          Carsten Michel
                          Huaimo Chen
                          Yuanlong Jiang
	Filename        : draft-ietf-mpls-egress-protection-framework-02.txt
	Pages           : 28
	Date            : 2018-07-19

Abstract:
   This document specifies a fast reroute framework for protecting IP/
   MPLS services and MPLS transport tunnels against egress node and
   egress link failures.  In this framework, the penultimate-hop router
   of an MPLS tunnel acts as the point of local repair (PLR) for an
   egress node failure, and the egress router of the MPLS tunnel acts as
   the PLR for an egress link failure.  Each of them pre-establishes a
   bypass tunnel to a protector.  Upon an egress node or link failure,
   the corresponding PLR performs local failure detection and local
   repair, by rerouting packets over the corresponding bypass tunnel.
   The protector in turn performs context label switching or context IP
   forwarding to send the packets to the ultimate service
   destination(s).  This mechanism can be used to reduce traffic loss
   before global repair reacts to the failure and control plane
   protocols converge on the topology changes due to the failure.  The
   framework is applicable to all types of IP/MPLS services and MPLS
   tunnels.  Under the framework, service protocol extensions may be
   further specified to support service label distribution from an
   egress router to a protector.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mpls-egress-protection-framework-02
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-egress-protection-framework-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-egress-protection-framework-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: James Bensley <[email-masked]>
Date: Mon, 23 Jul 2018 21:52:51 +0100

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.

---

From: Yimin Shen <[email-masked]>
Date: Wed, 25 Jul 2018 14:25:11 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi All,

    [QUERY1]
    ....

    

    

    

    [QUERY2]

    [QUERY3]

    Kind regards,
    James.
    
    _______________________________________________
    mpls mailing list
    [email-masked]
    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=