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

[Yimin Shen <[e-mail]>]

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

    Mirja Kühlewind has entered the following ballot position for
    draft-ietf-pals-endpoint-fast-protection-04: No Objection
  
    
    
    ----------------------------------------------------------------------
    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'.
    
[yshen] I will do 1) as you suggested, and also scan the document and spell out acronyms that are missed out.  

    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."
    
[yshen] Will make this change.

    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?

[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.


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

[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:
    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?
    
[yshen] Yes, there have been implementations and deployments.


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