Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
Greg Mirsky <gregimirsky@gmail.com> Wed, 05 June 2019 17:56 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53A1201B0; Wed, 5 Jun 2019 10:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlFMG6IGQ2Gc; Wed, 5 Jun 2019 10:56:14 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23D112014E; Wed, 5 Jun 2019 10:56:13 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id k18so2239691ljc.11; Wed, 05 Jun 2019 10:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KllETUWk/H0kvt/7RhIQhpY61rOLSgjalZB1dDMXwgk=; b=AC5HkH9OxwunZSr7izbzjUDtU0PH1LaRQZ+mwRJLQgr/a47/Ev7KyMJhCEU7vqb6c2 OHmSVXuH0keMBnB5TRHfHNeJMD6SZrDZknYjYZlT81PAp9OSmhHypp9MolDPJyxdtURK 2GfIVuaFRu6VCwbg2K6dGpICvZcQnrDc/HqZ2PjKG+NdsclRVxxzO+fh2Y3s9x8KCX9P hZV5G4qRjSQlIuRmp+67+v4QlzqUaWeIGQRuLpU1EgfstK5+r6nyId+pvareTFE30uXG OpMfuux0DAdN3x5zGng07WmalsDLiBp49Ggn9wkdM53JMknonA5vk/4qRelPWlKukuRe /H5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KllETUWk/H0kvt/7RhIQhpY61rOLSgjalZB1dDMXwgk=; b=GQtMZEiX9T0VxtX0E9gVavRMa7xnCeyT8Pj0guab8F5XHypbvYjANRJ0OqCHlghqXU aPsRGM79wjr08pBTPloeky7qnvpEUHmkjnauZDbc3NkS/BQEubFvbmP8TAhd4WdHr3gF S5P0/0R+JvsWlcsjxZY5MUA46tFbUdVVUFcSMyhbBuAiU272njyKyMlciVYUvKEpt5uu TWXB+dexXgYHPvrcVnsbQkjKO+R0XDG0qYeg0HKGJxV0hNTzTIdEQKF+hGmMCaeiawV7 P1CEycTljqhUYZ+sxSdOXmz0rXb0dwQEB4KtFmvdApWGJMyciZ2ZssINpuJgQMO1dhGu +sHg==
X-Gm-Message-State: APjAAAW2JbarCBuQc22dlK55wadxUxNNT3UXnEZcFykscyihk6HMN6MS JhWN56dS0MFn85XRh3uueTAgifJ5U6zMNnKzJ3yXqKPSJU0=
X-Google-Smtp-Source: APXvYqz2kXclGKcKhwTOiKrKYIEQEitJUfbhW3CuATSIra/wzO4RujW5TxnbyS1rnMIIzs85i8szR6jS/vSUg1t+Pjg=
X-Received: by 2002:a2e:96c3:: with SMTP id d3mr10263680ljj.68.1559757371735; Wed, 05 Jun 2019 10:56:11 -0700 (PDT)
MIME-Version: 1.0
References: <26502_1542873261_5BF660AD_26502_47_1_9E32478DFA9976438E7A22F69B08FF924B7752E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <BL0PR05MB5025A934922FDDC316AFD2E4D4AC0@BL0PR05MB5025.namprd05.prod.outlook.com> <CA+RyBmXcu3b9dObX=G9vyHNJtEuJ4wWqMtQXvxCNxgNOSCsmWw@mail.gmail.com> <CO2PR05MB24550CC9932A560B1DC7B19BD44B0@CO2PR05MB2455.namprd05.prod.outlook.com> <CA+RyBmV6oigz+ODY9C6QEqkDQY1X+x=yDpWqPoiODyyqVeTwHA@mail.gmail.com> <DM5PR05MB354829730C814ADE41F373CFD4310@DM5PR05MB3548.namprd05.prod.outlook.com> <CA+RyBmWNmdavTzoeGK+b1Tz-am6foNJ=1c5Kz7iKJ1gc7Lsvcg@mail.gmail.com>
In-Reply-To: <CA+RyBmWNmdavTzoeGK+b1Tz-am6foNJ=1c5Kz7iKJ1gc7Lsvcg@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 05 Jun 2019 10:56:00 -0700
Message-ID: <CA+RyBmXqqCCx1enb7Vd3AebzK=Xy0tubO=GGfZrpLVzv6x9ozQ@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Robert Kebler <rkebler@juniper.net>, BESS <bess@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000001430b7058a9750e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ekKuG5ejy0lf2VSubyOLxFC61n8>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2019 17:56:20 -0000
Hi Jeffrey, hope everything is well with you. I hope you can find time to review the proposed changes to address your comments. Best regards, Greg On Sat, May 11, 2019 at 12:23 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Jeffrey, > thank you for your consideration and the detailed comments with great > suggestions. Please find my answers below under GIM3>> tag. Attached is the > diff to highlight the updates. > > Regards, > Greg > > On Tue, May 7, 2019 at 7:43 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> > wrote: > >> Hi Greg, >> >> >> >> Most of changes are fine; though I suggest to replace the following: >> >> >> >> For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is >> >> considered up if one or more of the P2MP RSVP-TE LSPs to the same PE, >> >> identified by the P-tunnel Attribute, are in Up state. >> >> >> >> With the following: >> >> >> >> For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is >> >> considered up if the sub-LSP to this downstream PE is in Up state. >> > GIM3>> Accept with one question. As this is the first sentence in the > section, what is the PE we refer to as "this downstream PE"? Should we use > "a downstream PE"? > >> >> >> Not all comments have been addressed, though. I trimmed some text below >> and highlighted the outstanding ones with “=============”. You may need to >> refer to my previous email for correlation/details. >> >> >> >> Jeffrey >> >> >> >> On Thu, Mar 14, 2019 at 3:04 AM Jeffrey (Zhaohui) Zhang < >> zzhang@juniper.net> wrote: >> >> Thomas, Bob, >> >> >> >> Some questions below for you. Some old, and some new. >> >> ============================== >> >> >> >> >> >> Zzh> It’s not that the “rules … are not consistent”. It’s that by nature >> some PEs may think the tunnel is down while the others may think the tunnel >> is still up (because they’re on different tunnel branches), even when they >> follow the same rules. Traffic duplication in this case is also only with >> inclusive tunnels – so how about the following? >> >> >> >> Because all PEs may arrive at a different >> >> conclusion regarding the state of the tunnel, >> >> procedures described in Section 9.1.1 of [RFC 6513] MUST be used >> >> when using inclusive tunnels. >> >> GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions > about RFC2119-like language? > > >> =============================== >> >> Additionally, the text in section 3 seems to be more biased on Single >> Forwarder Election choosing the UMH with the highest IP address. Section 5 >> of RFC6513 also describes two other options, hashing or based on “installed >> UMH route” (aka unicast-based). It is not clear how the text in this >> document applies to hashing based selection, and I don’t see how the text >> applies to unicast-based selection. Some rewording/clarification are needed >> here. >> >> GIM>> How would the use of an alternative UMH selection algorithm change >> documented use of p2mp BFD? Do you think that if the Upstream PE selected >> using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself >> no longer applicable? >> >> >> >> Zzh> It’s not that the alternative UMH selection algorithm change >> documented use of p2mp BFD. It’s the other way around – tunnel state >> changes the selection result. I guess hashing can still be used (this >> document only controls what goes into the candidate pool). For unicast >> based selection I thought it’d no longer work, but then I noticed the >> following: >> >> >> >> o second, the UMH candidates that advertise a PMSI bound to a tunnel >> >> that is "down" -- these will thus be used as a last resort to >> >> ensure a graceful fallback to the basic MVPN UMH selection >> >> procedures in the hypothetical case where a false negative would >> >> occur when determining the status of all tunnels >> >> >> >> Zzh> So this should still work, although Ideally, the PE advertising the >> next best route should be considered before going to the last resort (of >> using the PE advertising the best route but whose tunnel is down). >> >> GIM3>> I hope I've got the idea. Below is the updated text (second > becomes third and your proposal - second): > NEW TEXT: > o Second, the PE advertising the next best route is to be > considered. > > o Third, the UMH candidates that advertise a PMSI bound to a tunnel > that is "down" -- these will thus be used as a last resort to > ensure a graceful fallback to the basic MVPN UMH selection > procedures in the hypothetical case where a false negative would > occur when determining the status of all tunnels. > >> ======================================== >> >> zzh> BTW, the same applies to 3.1.7 as well. >> >> GIM>> Agree >> > >> >> ================================== >> >> >> >> 3.1.7. Per PE-CE link BFD Discriminator >> >> >> >> The following approach is defined for the fast failover in response >> >> to the detection of PE-CE link failures, in which UMH selection for a >> >> given C-multicast route takes into account the state of the BFD >> >> session associated with the state of the upstream PE-CE link. >> >> >> >> 3.1.7.1. Upstream PE Procedures >> >> >> >> For each protected PE-CE link, the upstream PE initiates a multipoint >> >> BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward >> >> downstream PEs. A downstream PE monitors the state of the p2mp >> >> session as MultipointTail and MAY interpret transition of the BFD >> >> session into Down state as the indication of the associated PE-CE >> >> link being down. >> >> >> >> Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, >> my understanding is that the BFD discriminator is still for the tunnel and >> not tied to the PE-CE link; but different from the previous case, the root >> will stop sending BFD messages when it detects the PE-CE link failure. As >> far as the egress PEs are concerned, they don’t know if it is the tunnel >> failure or PE-CE link failure. >> >> >> >> If my understanding is correct, the wording should be changed. >> >> GIM>> There are other than stopping transmission of BFD control packets >> ways to distinguish two conditions for the egress PE. For example, the >> MultipointHead MAY set the State to AdminDown and continue sending BFD >> control packets. If and when PE-CE link restored to Up, the MultipointHead >> can set the state to Up in the BFD control packet. >> >> ===================== this needs more discussion ===== >> >> ===== should be clear on which way is done – stop sending BFD message or >> use AdminDown >> >> ===== an PMSI may be used for many flows, which may use different PE-CE >> interfaces on the ingress PE. A downstream PE would not know which >> interface it should track for a particular flow. >> >> GIM3>> Thank you for helping me to understand the problem with PE-CE and > p2mp BFD. I've updated the paragraph is 3.1.7, I've found the better method > to indicate the PE-CE link failure to the downstream. Also, stress that > though it is likely that PE-CE association be 1:1, it is outside the scope > of the draft. Please let me know if the new text addresses your questions: > NEW TEXT: > The following approach is defined for the fast failover in response > to the detection of PE-CE link failures, in which UMH selection for a > given C-multicast route takes into account the state of the BFD > session associated with the state of the upstream PE-CE link. > According to section 6.8.17 [RFC5880], failure of a PE-CE link MAY be > communicated to the downstream PE by setting the bfd.LocalDiag of the > p2mp BFD session associated with this link to Concatenated Path Down > and/or Reverse Concatenated Path Down. The mechanism to communicate > the mapping between the PE-CE link and the associated BFD session is > outside the scope of this document. > > >> >> >> … If the route to the >> >> src/RP changes such that the RPF interface is changed to be a new PE- >> >> CE interface, then the upstream PE will update the S-PMSI A-D route >> >> with included BGP-BFD Attribute so that value of the BFD >> >> Discriminator is associated with the new RPF link. >> >> >> >> If the RPF interface changes on the upstream PE, why should it update the >> route to send a new discriminator? As long as there is a new RPF interface >> couldn’t the upstream PE do nothing but start tracking the new RPF >> interface? >> >> GIM>> I'll defer this one to Thomas and Rob. >> >> =========================================== >> >> Zzh> I re-read section 3.1.6 and 3.1.7 and have more questions 😊 >> >> Zzh> 3.1.6 seems to be about tracking tunnel itself while 3.1.7 is about >> tracking PE-CE interfaces. From an egress point of view, (how) does it know >> if the discriminator is for the tunnel or for PE-CE interface 1 or PE-CE >> interface 2? Does it even care? It seems to me that an egress PE would not >> need to care. If so, why are there different procedures for 3.1.6/3.1.7 (at >> least for the egress PE behavior)? Even for the upstream PE behavior, >> shouldn’t 3.1.6.1 apply to 3.1.7 as well? >> >> GIM>> Added the following text to the first paragraph of section 3.1.7: >> >> NEW TEXT: >> >> The mechanism to communicate the mapping between the PE-CE link >> >> and the associated BFD session is outside the scope of this document. >> >> >> >> =============== the above added text does not address my questions >> >> >> >> Regardless which way (the currently described way and my imagined way), >> some text should be added to discuss how the downstream would not switch to >> another upstream PE when the primary PE is just going through a RPF change. >> >> GIM>> Would appending the following text be acceptable to address your >> concern: >> >> NEW TEXT: >> >> To avoid unwarranted switchover a downstream PE MUST gracefully handle >> the >> >> updated S-PMSI A-D route and switch to the use of the associated BFD >> >> Discriminator value. >> >> ================= how that is done needs to be discussed >> >> GIM3>> I think that this is implementation issue and we just point to the > recommended behavior without prescribing what steps must be taken to > achieve it. > >> >> >> 4. Standby C-multicast route >> >> >> >> The procedures described below are limited to the case where the site >> >> that contains C-S is connected to exactly two PEs. The procedures >> >> require all the PEs of that MVPN to follow the single forwarder PE >> >> selection, as specified in [RFC6513]. >> >> >> >> >> >> Why would it not work with more than two upstream PEs? >> >> Why is it limited to single forwarder selection? What about unicast based >> selection? >> >> GIM>> Again, asking for Thomas and Rob to help.. >> >> ========================== >> >> >> >> >> >> Juniper Internal >> >
- [bess] WGLC, IPR and implementation poll for draf… stephane.litkowski
- Re: [bess] WGLC, IPR and implementation poll for … Thomas Morin
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Robert Kebler
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … stephane.litkowski
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Mankamana Mishra (mankamis)
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang