[Pce] Review of draft-zhang-pce-resource-sharing-10

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 26 September 2019 07:39 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9989E120816; Thu, 26 Sep 2019 00:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 sCs7Wb4rPPzJ; Thu, 26 Sep 2019 00:39:39 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D10812084B; Thu, 26 Sep 2019 00:39:36 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8Q7dXw3012803; Thu, 26 Sep 2019 08:39:34 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 839B02203B; Thu, 26 Sep 2019 08:39:33 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 6E9632203A; Thu, 26 Sep 2019 08:39:33 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.72.158]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8Q7dSVx022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Sep 2019 08:39:32 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-zhang-pce-resource-sharing@ietf.org
Cc: pce@ietf.org
Date: Thu, 26 Sep 2019 08:39:24 +0100
Organization: Old Dog Consulting
Message-ID: <00bc01d5743d$89693c20$9c3bb460$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdV0PBwa8hOvLNhiTAKngPKw4ETJNg==
Content-Language: en-gb
X-Originating-IP: 87.112.72.158
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24934.005
X-TM-AS-Result: No--18.786-10.0-31-10
X-imss-scan-details: No--18.786-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24934.005
X-TMASE-Result: 10--18.785500-10.000000
X-TMASE-MatchedRID: SZwsnQS1TAc/9d9Rtcc0Q6JVTu7sjgg1lFGUu7DBzhhtHpq0YbBRi2eG LC9y2ysxOHQMPkdZKVOJQE6dtGxyOUyO27FZOPGv7LuOEAY9BqT27Syjew41+LKeTtOdjMy61IT 6ihIyptbD+zC17DiLSqoqVJT6t2qTChTObk4Cb7/jxJDUku2PNhZSD+Gbjz3I7649n0TgA4k9Mh AW8ZTOY/F4AdJnW02pyhxVty87JW1zt4swJJfEYQPZZctd3P4BEDnDEqNPduqZfDRE1uqSgtWZD ZFp9sK+XZ9uwiJ9BzHiVHZUU4QDnpmvObnpEDjcFEiDvEGKJxbJ5SXtoJPLyDi//dZ3YI25tdBA /Ye69J0XxDANc7MuDgG+x76r1ZOgvUDyWU5LV4OdonALKgiNvKwmLjb7urxINadzXMzmvfo/sJJ rvRfE1Gitp0rwRDpPWYQ/NVzpo5Bo/KGUV8ExqIvNlIrJDKnMunSyiaV8TbP78VtsEK4eICyW7M C1GOnhzFzAoAIAqP6+ScOGRvQ7A8TGhdajQJfFgLf5GeDY2qMOZNXmvnJaen8ozV5Wwb505sZTw YHfBM7aaz6XaPMQyiifxa8hl4apkbfFSBkmVVc05OiRm60IbgeCHewokHM/pUhsal26H0dRLTER hRg1g2re8N4zYSDbg25QWLQyM7uZRBKsj/jrq8y6PPK75b2BPJb7oABYhT+fcVJ8cL8ZO3/WDu2 EM8cZB5lYfN/XeVp5xMgAEHdrO09OXLef1sAMM8XTtgUzttOaIhErJt0dLAbYcy9YQl6ebxTyq4 Bg+pCh9bMmqe83MQdiJPnMXEw20yMP1QZOu5KeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg/cUt5lc1lLgtT4piLWpY7p+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/kH9gKq-t-CZB-QrkBMet-tf2NHM>
Subject: [Pce] Review of draft-zhang-pce-resource-sharing-10
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 07:39:43 -0000

Hi,

Now I'm no longer one of the PCE chairs, I have a little more time for
reviewing works in progress.

This document popped up as a candidate because it has been around for a
long time and is now on its eleventh version. (It's also not too long,
which makes it attractive.)

I hope these comments are useful.

Best,
Adrian

===

Title

OLD
    Extensions to Path Computation Element Protocol (PCEP) to Support
                Resource Sharing-based Path Computation
NEW
  Extensions to the Path Computation Element Protocol (PCEP) to Support
                Resource Sharing-based Path Computation
END

---

Boilerplate

You should reorganise the header sections to match with the current
best practice. That it:

Title
File name
Abstract
Status of this memo
Copyright
Table of contents

The requirements language should be moved to Section 1.1 or Section 2
where you should use the latest form of words...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

That also gives you an additional Normative reference for 8174.

---

Optional plurals. In English you do not need say things like "use common
piece(s)". You can use the unequivocal plural and it is understood that
it is optional. So you should say "use common pieces".

Please s/(s)/s/ throughout the document.

---

In the Abstract you have a use of "PCEP" before the expansion of the
term.

---

The last words of the Abstract are:
   which is a special case in the association path computation.

This is slightly confusing because you haven't established what
"association path computation" is. I suggest you might change the
Abstract to read something like:

   Resource sharing in a network means two or more Label Switched Paths
   (LSPs) use common piece(s) of resource along their paths. This can
   help save network resource and is useful in scenarios such as LSP
   recovery or when two LSPs do not need to be active at the same time.
   A Path Computation Element (PCE) is responsible for path computation
   with such requirement.

   Existing extensions to the Path Computation Element Protocol (PCEP)
   allow one path computation request for an LSP to be associated with
   other (existing) LSPs through the use of the PCEP Association Object.

   The resource-sharing-based path computation
   with better efficiency can be achieved together with the association
   object in PCEP.

   This document extends PCEP to support resource sharing-based path
   computation as another use of the Association Object.

---

Section 1

OLD
   provides an alternative way for providing
NEW
   is a way to provide
END

Since "passive" and "active" have not yet been mentioned...
OLD
   Unless specified, this
   document assumes a PCE mentioned is a stateful PCE (either passive
   or active).
NEW
   Unless specified, this
   document assumes a PCE mentioned is a stateful PCE.
END

---

Global search and replace "a LSP" to "an LSP"

---

In Section 1 you have:

   Furthermore, if there is resource sharing between new LSP and
   existing LSP, the two LSPs cannot exist simultaneously, the new LSP
   will replace the existing LSP(s).

I know why you say this, because (obviously) you can't double-book
resources. But I think that you can relax the requirement here especially
for the case of protection and restoration. All you actually need is
that both LSPs can't be active (i.e., carry traffic) at the same time.

Actually, a little while later you talk about make-before-break where
(obviously) both LSPs can exist at the same time.

Of course, this is not a concern for the PCE, just for the LSP head-end,
so perhaps it isn't a requirement to state here. Maybe just state it as
an observation in this paragraph.

But you will need to clean up the hole text, I think. For example, a
little later you have:
   However, these objects
   are used to describe the relationship with two simultaneous LSPs,
   instead of a new one and an old one, which is different with the
   object proposed in this draft.
...and you say that like only one of the two LSPs will exist at any
time, but (again) that is not consistent with MBB or other forms of
protection. So this could be clarified to mean "used to carry traffic".

---

In Section 1

   but also the same slice of bandwidth in TDM networks.

While true, this appears to be limiting to TDM where, I think, you
intend the document to apply to any technology. So how about:

   but also the same slice of bandwidth in the network.

---

Throughout the document, where you have written "this draft" say "this
document" to future-proof yourself against becoming an RFC.

Similarly s/proposed/defined/

---

Section 1

   As mentioned in [RFC8231], the PLSP-ID is unique during a PCEP
   session between PCC and PCE. Such identification is helpful in
   supporting the above resource sharing requirement for
   standardization of stateful PCEs.  With a unique identifier, the
   configuration of PCCs is greatly simplified. Instead of determining
   all the resources to be shared, the PCC could request resource
   sharing directly from PCE.

This might be better as...

   As mentioned in [RFC8231], the PLSP-ID provides a unique identifier
   for an LSP during a PCEP session between PCC and PCE. Such
   identification is helpful in supporting the resource sharing
   requirement for stateful PCEs because it greatly simplifies the
   operation of a PCC. Instead of the PCC determining all the resources
   to be shared, the PCC can request that the PCE share the resources of
   a specific LSP: the stateful PCE is able to determine those resources
   itself.

---

Section 1

   In a multi-layer network, Label Switched Paths (LSPs) in a lower

No need to expand "LSP" a second time, here.

---

There is some misalignment of the sides of the stateful PCE in Figure 1

---

Section 2.1

   If resources are shared
   between the old and new LSPs, there will be some 'interruption' when
   the traffic is switched from the old LSP to the new LSP.

and later

   On the other hand, in some scenarios there are different policies,
   for example the LSP should be restored without any interruption with
   best effort.

Well, didn't link N2-N3 just fail? So the interruption is probably
already quite significant.

You do go on to say
   An example can be found in Fig. 1 without failure on
   N2-N3 link, instead, an online re-optimization is needed for the
   working LSP (N1-N2-N3) from the stateful PCE.

So I think you need to sort out two cases:
1. Repair after failure
2. Re-routing for optimization (or other reasons)

For these, you may want to explain the benefits of shared resources:
- may not be enough resource in the network to set up the 2nd LSP
- may want to keep the 2nd LSP on the shortest path and might not be
  enough resources to do that
- may want to reduce network programming time
- may have some resource continuity (such as lambda) constraints
But also the drawbacks:
- switch-over in MBB may take longer because multiple nodes have to
  act to effect the switch
- switch-over coordination may be harder because switching nodes are
  remote from the LSP end-points

Your example LSP1 and LSP2 do highlight this successfully.

---

I wonder whether Section 2.1 should also include notifying the PCE of
which resources to avoid. That would certainly include the failed link
(I am not sure that we can assume that the PCE has learned about the
failure [through the IGP] as fast as the PCC learned about it through
fault notification or signalling), but it might also include non-failed
in case of rerouting [such as before planned maintenance]).

---

The top of LSR H5 has become detached in Figure 2

---

The diagonals in Figure 3 are hard on the eye. Can you use single lines?

Maybe...

                         +----------------------+
                         |        P-PCE         |
                         +----------+-----------+
                        /           |            \
                       /            |             \
                      /             |              \
                     /              |               \
                    /               |                \
                   /                |                 \
           +------+             +---+---+              +------+
           |C-PCE1|             |C-PCE2 |              |C-PCE3|
           +------+             +-------+              +------+

     ______________       ______________________      ______________
    /               \    /                      \    /              \
   | +---+     +---+ |  |  +---+   +---+   +---+ |  | +---+    +---+ |
   | | A +-----+ B +-+--+--+ D +---+ E +---+ H +-+--+-+ J +----+ L | |
   | +---+     +---+ |  |  +---+   +---+   +---+ |  | +---+    +-+-+ |
   |      \          |  |         /             \|  |           /    |
   |       \         |  |        /               +  |          /     |
   |        \        |  |       /                |\ |         /      |
   |         \ +---+ |  |  +---+                 | \|    +---+       |
   |          \| C +-+--+--+ G |                 |  +----| K |       |
   |           +---+ |  |  +---+                 |  |    +---+       |
    \_______________/    \______________________/    \______________/


---

In 3.1 you have:

   A sharing group should have multiple LSPs. The number of LSPs and
   the criteria for how LSPs share among each other are implementation
   dependent. Local path computation policies apply to different PCE
   and PCC, some examples can be found in section 2.

I wonder whether "implementation dependent" might be better as
"dependent on local policy".

---

Section 3.2 has:

   The PCEP Resource Sharing group MUST carry the following TLV. It MAY
   be carried within a PCReq message from the network element (or other
   PCCs) so as to indicate the desired resource sharing requirements to
   be applied by the stateful PCE during path computation.

It feels like a contradiction between the "MUST" and the "MAY".

---

The figure in 3.2 seems to have surplus blank lines inserted.

---

Section 3.2

Flags L, N, and B all say that the PCE "should prioritise" something.
That is OK, but what happens if more than one bit is set? How are the
prioritisations prioritised?

---

Section 3.3

     - If the Resource Sharing TLV is unknown/unsupported, the PCE will
     follow procedures defined in [RFC5440].  That is, the PCE sends a
     PCErr message with error type 3 or 4 (Unknown / Not supported
     object) and error value 1 or 2 (unknown / unsupported object class
     / object type), and the related path computation request is
     discarded.

     - If Resource Sharing TLV are unknown/unsupported and the P bit is
     set, the PCE MUST send a PCErr message with error type 3 or 4
     (Unknown / Not supported object) and error value 4
     (Unrecognized/Unsupported parameter), and the related path
     computation request MUST be discarded as defined in [RFC5440].

Now I'm confused! Is this a TLV or an Object? And how are these two
paragraphs compatible? (I think it is a TLV.)

---

Section 3.3

     - If the resource sharing TLV is extracted correctly, the PCE MUST
     apply the requested resource sharing requirement.

Yes, OK. Except that you have said this is subject to local policy which
could (of course) mean that no sharing is done or even attempted.

---

Section 3.3

Can you expand RSO on first use.

---

According to WG policy, you'll need to include an "Implementation
Status" section. Put it in now, even if you only say that you are not
aware of any implementations at the moment.

---

I'd love to see a Manageability Considerations section. It isn't
compulsory, but it has become normal for the PCE WG. And you have
some management things to talk about as you mention policies, and
also as you have to coordinate alerts/fault reports from the network.

You also have "The RSO flags may be locally configured..."

---

Section 5.1 uses "TBA" but the txt uses "TBD" Please align these.

---

Section 5.1 needs a little more detail to correctly direct IANA to the
registry. You need some text such as...

   IANA maintains a registry called the "Path Computation Element
   Protocol (PCEP) Numbers" registry with a subregistry called the
   "Association Type Field" subregistry.  IANA is requested to make
   an assignment from that subregistry as follows:

   Type |   Name               | Reference
   -----+----------------------+---------------
   TBD1 | Sharing Association  | [this.I-D]

---

The heading of Section 5.2 has become indented

---

Section 5.2

This section seems a bit jumbled. Have a look at Section 7.2 of
draft-ietf-pce-association-diversity.

You have numbered the bits from 0 as the right-hand bit, but the figure
in section 3.2 has them numbered in the opposite way. You need to be
consistent or include an explanation. Again, modeling on draft-ietf-pce-
association-diversity might help.

---

It would be helpful if you included the filename in the reference
[H-PCE].  I think this is draft-ietf-pce-stateful-hpce.

---

The Contributors section is hiding inside the Authors' Addresses and I
missed it. I think that is just an indentation problem.