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

[Zhenghaomian <[e-mail]>]

Hi, Adrian, 

Thank you for the help and comments, we will address and update in the next version. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Adrian Farrel [mailto:[e-mail]] 
发送时间: 2019年9月26日 15:39
收件人: [e-mail]
抄送: [e-mail]
主题: Review of draft-zhang-pce-resource-sharing-10

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.