Subject: [Pals] Mirja Kühlewind's No Objection on draft-ietf-pals-endpoint-fast-protection-04: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 14 Dec 2016 05:32:31 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pals-endpoint-fast-protection-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few smallish comments/questions:

1) This is no news but there are a lot of acronyms in this drafts which
makes it partly hard to read. Some of them are never spelled out, such as
PE, CE, RSVP... I would like to propose two changes to support the
reader: 1) Spell out all acronyms in the abstract and 2) add a glossary.
Further you could maybe also define some terminology at the beginning
such as 'protector'.

2) This sentence/use of acronym is confusing: 
"In Figure 1, the IP/MPLS network consists of PE and P routers."
NEW:
"In Figure 1, the IP/MPLS network consists of four PEs and two routers P1
and P2."

3) I don't fully understand this part in sec 4.1:
"Normally the router will attempt to
   forward PW packets in a load balance fashion over the ECMP set.  When
   the link fails, if the router reroutes only the portion of traffic
   originally traversing the link while letting the rest of traffic
   remain on the other ECMP branches, it will create a situation where
   the egress CE receives traffic from both the primary PE and the
   backup PE. "
If you have two ECMP branches, why don't you simply use the other one for
all traffic? Isn't this the kind of protection your are discussing? Or
are you assuming that this note somewhere on the PW does not apply this
backup strategy?

4) Do you have references for mechanisms described in section 5?

One high level comment:
I was wondering while reading the whole time if this should be
informational or standards track. Was there any discussion in the wg? Are
there implementations?

---

From: Yimin Shen <[email-masked]>
Date: Fri, 16 Dec 2016 17:02:52 +0000

Hi Mirja,

Thanks very much for your review and comments! Please see my answers inline.

Thanks,

-- Yimin

On 12/14/16, 8:32 AM, "Pals on behalf of Mirja Kuehlewind" <[email-masked] on behalf of [email-masked]> wrote:

    

    
[yshen] I will do 1) as you suggested, and also scan the document and spell out acronyms that are missed out.  

[yshen] Will make this change.

[yshen] ECMP branches can only be used to protected each other (in the manner you mentioned), if the failure on one branch is not shared by other branches. This condition may hold in some cases of transit link/node failure, but not in an egress node failure. At the moment that we detect an egress node failure on any ECMP branch, we should know this failure is going to affect all ECMP branches (i.e. the entire tunnel). Therefore, despite the current state of the other branches (as some of them may not be direct links to the egress node, and hence subject to delay in failure detection or propagation), we should move all traffic to the bypass LSP. I will revise the text to clarify this.

[yshen] In general, a network has a numbers of options to react to a failure (while local repair is in use) and eventually converge. We have seen all them being used in real networks. In this section, we list them for the completeness of the document, to provide to overview on what to expect after egress protection kicks in.  Section 6.5.2 of RFC 4090 has a similar discussion in the context of RSVP, but I don’t think this document should refer to that, because all these mechanisms are protocol independent and common practices.
    
    One high level comment:
    
[yshen] Yes, there have been implementations and deployments.

    _______________________________________________
    Pals mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/pals