Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 20 June 2017 21:12 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91492129486; Tue, 20 Jun 2017 14:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 9W1b5VcbxFEC; Tue, 20 Jun 2017 14:12:31 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 38037129417; Tue, 20 Jun 2017 14:12:31 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id l75so57387913ywc.3; Tue, 20 Jun 2017 14:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+cTIZcDAad/2JAwbhNSeghh0S+uOFJyW0ttfgAe5jB8=; b=dfGSHDF/rdyq/d3XkIVHVCXur698HM9E/A2Cu/jqOdfgf7ocFfqO0+bRzGuNYqiXOf 4Dg1xsF0u/PEp9+v2gZiPDll/B8U0lq0E2t8uCWR9B3KzGxFyhINQ0VzDFCnI/JiLpuD zm1IIpioA5rmRL2TVopC9a3dU7bOZQW6/16CiPChSSUVIBGvERIsQDD0xnDiFqnMyVNP GEnozvSVzzkxzmXH9wRbzU00sCMoB13x8j0mFiWnrQGqXhWXfwa6thJHQtLVFu2MJpT1 FC9MP8mNIJgrNLb8lwghLUpMobe//iNdDJVt69MXgzOBHCwL0xMoqcqyO2EfP4oCTfE3 KCpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+cTIZcDAad/2JAwbhNSeghh0S+uOFJyW0ttfgAe5jB8=; b=ajIzsZpg9S0rc34Z3sNqVyleyVbhoMMLA+doXroWmOuklsIGxeUpkSGNsjoN4SEXYt TGsKDEl1K6zeLcAy34n4QcKQ4KS/l7KsUZex9AS+ZizoorLJCQhwuBfrCHVarkyMiNJI ZAFXJ8vXGzX5TpNgdZn8uNEdTnjOjcmBVCVkyxW+rvSaUN3qDp5dquvneCoPfdubQEQ1 jtWEs45jgsQ9mwThHXgAfrL09ZLZtlIeT9Y36UmUTnUlL2izFfopwQvqKgd50Xc3HZig OKdGagoycZVRNWJr/boawKGmGB7lFkSerALBcberm1TAAbXJTtf8o66Gefls7rVXmm19 b28w==
X-Gm-Message-State: AKS2vOydqoIyYLWsqBRs9WYHirEmEmfxI2jH3fqwCq/Fla9M9zgJ75QP qTXmlH0QvK2xSrvuraxNHICOij8hHA==
X-Received: by 10.129.130.71 with SMTP id s68mr25497403ywf.42.1497993150175; Tue, 20 Jun 2017 14:12:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.216.85 with HTTP; Tue, 20 Jun 2017 14:12:29 -0700 (PDT)
In-Reply-To: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com>
References: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 20 Jun 2017 16:12:29 -0500
Message-ID: <CAKKJt-fsy96LXCUR9PCjxFAq64tJbqtVm_ewQpOJ61x0uZrSjQ@mail.gmail.com>
To: The IESG <iesg@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-tp-shared-ring-protection@ietf.org, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Eric Gray <Eric.Gray@ericsson.com>
Content-Type: multipart/alternative; boundary="94eb2c07c8a497b85a05526ab584"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BAAOoNK3h6fH8vz1zm9daJq8Nvo>
Subject: Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jun 2017 21:12:35 -0000
Jimmy has asked whether -06 works for me. The easiest way for me to reply to that, is from my original ballot, but I'm looking at Huub's e-mails in this thread. So, see below. On Wed, May 24, 2017 at 3:10 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-mpls-tp-shared-ring-protection-05: Discuss > > 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-mpls-tp-shared- > ring-protection/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I want to thank the authors for a very readable draft. It was a pleasure > to review, and that's a high bar for the subject. > > I have loads of questions, but my first set of questions is an expansion > of Alvaro's comment that I think rises to the level of a Discuss. Please > note that I'm asking questions, not proposing text changes, so I really > do want to discuss it. > > ---------- my first set of questions > > In this text, > > Three typical ring protection mechanisms are described in this > section: wrapping, short wrapping and steering. All nodes on the > same ring MUST use the same protection mechanism. > > I would like to understand what happens if they aren't - and I'm asking, > mostly as a way of encouraging guidance for operators in debugging cases > where they're not all using the same mechanism. I'm not asking for a full > mesh of possible misconfigurations, only for a sentence or two ("If they > aren't all using the same protection mechanism, the following things may > happen"). > Huub's additional text worked for me here. > More broadly, I'd like to understand why wrapping and short wrapping are > both defined. It seems like the only functional difference is that short > wrapping doesn't give you as much latency. Is that right? > > 24 pages in, I see this: > > o In rings utilizing the wrapping protection, each node detects the > failure or receives the RPS request as the destination node MUST > perform the switch from/to the working ring tunnels to/from the > protection ring tunnels if it has no higher priority active RPS > request. > > o In rings utilizing the short wrapping protection, each node > detects the failure or receives the RPS request as the > destination > node MUST perform the switch only from the working ring tunnels > to > the protection ring tunnels. > > so I'm pretty sure there are differences beyond what I was seeing, > earlier in the document. > I think Huub's proposed text addressed this. > > And, of course, I'm not sure what the effect of choosing steering over > wrapping/short wrapping would be, for my users, but that can wait until > we talk about wrapping and short wrapping ... > And this. > > At a minimum, I'd like to see guidance for operators in choosing among > the three protection mechanisms. Why would they choose any one of the > three? > Section 7 is what I was hoping for. It's likely that a forward pointer to this section, early in the document, would be helpful for your readers. Do the right thing. > > I also note that this MUST seems to be repeated using different words in > section 5.1, as > > All nodes in the same ring MUST use the same protection mechanism, > Wrapping, steering or short-wrapping. > > If that's saying the same thing, one MUST is all you need. > So, that went away. SO I CAN CLEAR MY DISCUSS ... but just to check on my comments :-) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ---------- all the other questions > > In this text, > > When the service LSP passes through the interconnected rings, the > direction of the working ring tunnels used on both rings SHOULD be > the same. For example, if the service LSP uses the clockwise > working > ring tunnel on Ring1, when the service LSP leaves Ring1 and enters > Ring2, the working ring tunnel used on Ring2 SHOULD also follow the > clockwise direction. > > I'm not understanding why this is a SHOULD, and not a MUST. If the > direction of the working ring tunnels used on both rings is not the same, > does this still work? > > If it still works, why does this matter? But, either way, you might > usefully say something about why this isn't always the right thing to do, > even if you just give one example. The point of SHOULD is that > implementers make their own informed decisions, so providing information > that will inform those decisions seems important. > Huub's additional text was very helpful in explaining what's going on here. > > I wanted to call out > > Ring switches MUST be preempted by higher priority RPS requests. > For > example, consider a protection switch that is active due to a manual > switch request on the given link, and another protection switch is > required due to a failure on another link. Then an RPS request MUST > be generated, the former protection switch MUST be dropped, and the > latter protection switch established. > > MSRP mechanism SHOULD support multiple protection switches in the > ring, resulting in the ring being segmented into two or more > separate > segments. This may happen when several RPS requests of the same > priority exist in the ring due to multiple failures or external > switch commands. > > as really good examples of the kind of text I think would help the places > in this document ("For example", "This may happen when") where no > examples are given. Thanks for providing those examples! > > Ouch. Do I understand from > > o Protection Switching Mode (M): This 2-bit field indicates the > protection switching mode used by the sending node of the RPS > message. This can be used to check that the ring nodes on the > same ring use the same protection switching mechanism. The > defined values of the M field are listed as below: > > +------------------+-----------------------------+ > | Bits (MSB-LSB) | Protecton Switching Mode | > +------------------+-----------------------------+ > | 0 0 | Reserved | > | 0 1 | Wrapping | > | 1 0 | Short Wrapping | > | 1 1 | Steering | > +------------------+-----------------------------+ > > that you already have three protection mechanisms, and have only one > possible codepoint to allocate for any future optimizations? Assuming > that "0 0" can be unReserved ... > Huub's explanation helped me with this one. > > Could you clarify what "anyway" means in this text? > > When multiple MS RPS requests exist at the same time addressing > different links and there is no higher priority request on the ring, > no switch SHOULD be executed and existing switches MUST be dropped. > The nodes MUST signal, anyway, the MS RPS request code. > Thanks for this one. > > I'm seeing that the commands like LP described in section 5.2.1.1 are > used in the document before these (I'm serious) helpful and clear > explanations appear. If it's possible to move section 5.2.1.1 up in the > document, that would be great, but if it isn't possible, a forward > pointer would be helpful to readers who don't already know what the > command abbreviations mean. > Thanks for the forward pointer. > > I'm really confused by this SHOULD: > > The PSC protocol [RFC6378] is designed for point-to-point LSPs, on > which the protection switching can only be performed on one or both > of the end points of the LSP. The RPS protocol is designed for ring > tunnels, which consist of multiple ring nodes, and the failure could > happen on any segment of the ring, thus RPS SHOULD be capable of > identifying and handling the different failures on the ring, and > coordinating the protection switching behavior of all the nodes on > the ring. > > I suspect that's because it's not a 2119 SHOULD, but if people think it > is, I wouldn't mind understanding why. > Thanks for fixing this. > > Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful, > but it appears 43 pages in. Given that I'd expect people to be asking why > they should implement a new protection switching protocol when they've > already implemented PSC, I'd think this would be much more useful, early > in the document. > There's more text, and it looks helpful, but I still think it would be more useful, much earlier in the document. Do the right thing :-) ... > > I'm somewhat confused about the code point allocation strategy in this > text: > > The RPS Request Field is 8 bits, the allocated values are as > follows: > > Value Description Reference > ------- --------------------------- --------------- > 0 No Request (NR) this document > 1 Reverse Request (RR) this document > 2 unassigned > 3 Exercise (EXER) this document > 4 unassigned > 5 Wait-To-Restore (WTR) this document > 6 Manual Switch (MS) this document > 7-10 unassigned > 11 Signal Fail (SF) this document > 12 unassigned > 13 Forced Switch (FS) this document > 14 unassigned > 15 Lockout of Protection (LP) this document > 16-254 unassigned > 255 Reserved > > My first question is, why the highest priority RPS value is 15, given > that the field is 8 bits wide. If anyone ever needs to add a code point > higher than the highest priority code point, will that work well? I can > imagine code that says "if operation_priority is greater than > highest_priority, it's an error", for example. > > I may have other questions depending on your answer, but let's start > there. > Huub's explanation helped a lot. So, I'll go clear now, and thanks for working through my Discuss. Spencer
- [mpls] Spencer Dawkins' Discuss on draft-ietf-mpl… Spencer Dawkins
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Huub van Helvoort
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Alvaro Retana (aretana)
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Huub van Helvoort
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' Discuss on draft-ietf… Dongjie (Jimmy)