Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)

Huub van Helvoort <huubatwork@gmail.com> Thu, 25 May 2017 10:02 UTC

Return-Path: <huubatwork@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 D549312EA5A; Thu, 25 May 2017 03:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 LbPGDjx0BRO8; Thu, 25 May 2017 03:02:10 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 2514A12E058; Thu, 25 May 2017 03:02:10 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id g15so32128206wmc.2; Thu, 25 May 2017 03:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AwXes+QMTEcQv193gj990tOISmi7fYJmsRnp8UXkZGA=; b=XkNY+bd7R7m3QDpuISUBAaXd/UQowUwjEAO26NzCItqnq70/RLJ2uoIAIGqvsXZ6kg Qh6eBIj1acpkXCqiBGMC/Wqb6qr96EeHL2KdrodEtViPTc6aMKa/p9w3k3PcLuMpgI8r rLDtubHkA80C+fUUhu+/dH/AbUs8jrqeEek76XEEHfinnvGizyvyTviQmsSiHwQKS7tN I2ARO5siDDMV8vg/5ZTNu0I8sH607aEOSIrHbduF6iwExuJhauX/Es8H4HUrP67Wx8Xz 6R1gKRvK2SW2gNe3FntouhrWdr5M2oZmGnbh4D61NwwPfbaJQ8YyALbcgiD7O1karipL PlVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AwXes+QMTEcQv193gj990tOISmi7fYJmsRnp8UXkZGA=; b=eYJngeF25wTzLiFBgIBpj7nvCYaaxnBCLeNv3dZ3PHtl+tdMbwF7fJ0Crp7if3YC06 MqHhWpV7dI1dPNCGuO/zuFGFrif17tvUJrcFtClgVAIpUayiAht4JrIUWpsp+Vp41/Mi EXBMbNVSCanzS3Cd3NpV/iBLGvfVQjZxMuNGYM0H6Uw+2Sm4z4dwJ9j+fvzEm0HmHEm0 WQJzuh25cKvoyx3f7j7pWp9seXWlxBhyZ4csbyitc9U4a9OBpTED51rqfke6FmoaC0fB B9M3+Oz9VqQmAir7mcQuvTjxfqE/f4rXHPfiP7D+KEcltfLfK0nmKU+YxOVz5db7nBJU SQYA==
X-Gm-Message-State: AODbwcBRzPcnF1QrcT1IV7WZf671jpely+tdgepVgDV4VWjmkoqGtiu5 vlSKVhDU5XqlRg==
X-Received: by 10.80.181.99 with SMTP id z32mr27721420edd.6.1495706528488; Thu, 25 May 2017 03:02:08 -0700 (PDT)
Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id b9sm2584114eda.46.2017.05.25.03.02.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 03:02:07 -0700 (PDT)
Reply-To: huubatwork@gmail.com
References: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray <Eric.Gray@Ericsson.com>, mpls-chairs@ietf.org, mpls@ietf.org
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <b342ad77-1cd2-ebc9-4c84-337eeb4a00e8@gmail.com>
Date: Thu, 25 May 2017 12:02:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/NXsntJLgIxWj3BsTJGRn-FAKQm8>
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: Thu, 25 May 2017 10:02:13 -0000

Hello Spencer,

Thank you for your review of our draft.
Please find my response in-line [Huub]

> Spencer Dawkins has entered the following ballot position for
> draft-ietf-mpls-tp-shared-ring-protection-05: Discuss
>
> 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.

[Huub] thank you!

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

[Huub] OK, understood.

> ---------- 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] if the MRPS protocol in any node detects RPS message with a
mode that was not provisioned in that node a failure of protocol will
be reported, and the protection mechanism will not be activated.

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

[Huub] wrapping is a mechanism that can be used in case an LSP is dropped
in several nodes (p-2-mp application). In this case the traffic will 
still have
to reach every node in the ring.
Short wrapping can be used only in p-2-p application. Now the traffic can
be dropped at the moment the egress node is reached.
Steering has the least additional propagation delay, but during a short time
the traffic may be duplicated, which may not be desirable is some 
applications.

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

[Huub] more explanatory text can be added, it could be in the introduction
proposed by Alvaro.

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

[Huub] OK, point taken.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ---------- all the other questions

[Huub] I will answer your questions later
(I am currently on holiday and risk a divorce if I don't stop now :-(  )

Best regards, Huub.

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


-- 
================================================================
Always remember that you are unique...just like everyone else...