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

[James Bensley <[e-mail]>]

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.