Re: [Pce] Poll for adoption: draft-litkowski-pce-association-diversity

[<[e-mail]>]

Hi Adrian,

We just posted a v01 that tried to address your comments.
Some encoding/procedures proposed still requires discussion for sure. Please let us know your feedback.

We have an on going discussion with the authors of the base association group draft. Your last point on security may be addressed by this document in a next revision as we think that it is a more general item.

Best regards,


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element of the IETF.

        Title           : Path Computation Element communication Protocol extension for signaling LSP diversity constraint
        Authors         : Stephane Litkowski
                          Siva Sivabalan
                          Colby Barth
                          Dhruv Dhody
	Filename        : draft-ietf-pce-association-diversity-01.txt
	Pages           : 17
	Date            : 2017-03-13

Abstract:
   This document introduces a simple mechanism to associate a group of
   Label Switched Paths (LSPs) via an extension to the Path Computation
   Element Communication Protocol (PCEP) with the purpose of computing
   diverse paths for those LSPs.  The proposed extension allows a PCC to
   advertise to a PCE the belonging of a particular LSP to a disjoint-
   group, thus the PCE knows that LSPs in the same group must be
   disjoint from each other.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-pce-association-diversity-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-01


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Saturday, January 14, 2017 18:08
To: 'Jonathan Hardwick'; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [Pce] Poll for adoption: draft-litkowski-pce-association-diversity

> This is start of a two week poll on making
draft-litkowski-pce-association-diversity-01 a PCE working group document.

Hi,

I support the adoption of this draft, because it is clear that this function needs to be provided. But my review throws up a few things that should be worked on. None of my issues needs hold up adoption of the document so long as we can agree to look at them as the work goes forward. Note that a few of my comments might lead to reducing the available function, and other might suggest using existing mechanisms rather than adding new features.

Thanks,
Adrian

===

Could the Abstract make it a little clearer whether this signaling is to request a PCE to compute diverse group of LSPs, request that a PCE compute the path of an LSP that is diverse from some other group of existing LSPs, indicate to a PCC that it must set up a group of diverse LSPs, indicate to a PCC that an LSP that is to be set up must be diverse from some other group of LSPs, or report from a PCC to a PCE that a group of LSPs are diverse.

In other words, give some indication of what the feature is for.

---

Similarly, the Introduction needs to give some more clue. When it says "used to signal" it fails to indicate who signals to whom and at what stage in the process.

---

The document needs to make it clear why the SVEC object is not a suitable approach. I think this will follow from the previous two points but it is important to mention SVEC and clarify the relationship to that object which has previously been used to enable "related" computations.

---

The caption to Figure 1 might better read...

Figure 1 - Disjoint paths with different head-ends and tail-ends

---

"PCInit" should, I think, be "PCInitiate".

---

I want to note that diverse paths can often only be successfully computed if they are computed as a batch. Therefore, a mechanism that allows one PCC to request an LSP "disjoint from everything else in this group" is flawed unless the PCE has some way to know the whole of the group. 
Otherwise, the PCE will compute the path of the LSP as the CSPF because the group is empty and will later get a second request ("compute a second LSP disjoint from the group") that it might not be able to satisfy. This problem is compounded by increasing the size of the group without the PCE even knowing whether it has information about the whole group.

That fact does not detract from the protocol mechanism, but does, I think, mean that the use case of two or more separate PCCs (LERs) requesting LSPs to be diverse from the group is either more complex (it could use rerouting to achieve the results after performing a "global concurrent reoptimization", or it could have additional protocol mechanisms to scope the group), or subject to failures or suboptimal results.

Note that SVEC, SVEC list, and GCO were previous attempts to address this specific problem. Just as OFs were previous ways of expressing the computation result desired.

---

In 4.1 you have...

   A disjoint group can have two or more LSPs.  But a PCE may be limited
   in how many LSPs it can take into account when computing
   disjointness: usually PCEs are able to compute a pair of disjoint
   paths.  If a PCE receives more LSPs in the group than it can handle
   in its computation algorithm, it SHOULD apply disjointness
   computation to only a subset of LSPs in the group.  The subset of
   disjoint LSPs will be decided by the implementation.

I think it would be good to strike ": usually PCEs are able to compute a pair of disjoint paths". That is an implementation detail and actually has no bearing on the protocol mechanism you define. That is, even if a PCE can only compute one path, the "subset" of one will work. 
(Personally, I think PCEs should be able to handle arbitrary groups, but I understand some algorithms differ.)

What is missing, however, is how the PCE in this case reports that it did not perform the requested function, but still supplied paths. That is, the paths are not what was requested, but are supplied as though they were. I believe the PCE MUST report this fact so that the PCC can decide whether or not to use the paths.

---

Similarly

   Associating a particular LSP to multiple disjoint groups is
   authorized from a protocol perspective, however there is no insurance
   that the PCE will be able to compute properly the multi-disjointness
   constraint.

So the PCE that cannot handle this case needs to have a formal response that lets the PCC know that something undesired has happened.

---

What is the interaction of the P flag and the OF?
If the OF says, for example, use the least load path, and yet the P flag is set, what should the PCE do?
Perhaps this is what your text is trying to talk about.
Maybe then, this isn't specifically the "shortest path" flag, but is more a "satisfy all constraints and objective functions first without considering the diversity constraint" flag.

Even so, you should talk about what happens if there are two paths that equally satisfy the other constraints and OFs (consider ECMP) but where the use of one allows diversity, and the use of the other does not.
(Hint: it is very easy to draw networks where this happens.)

---

How does the strictness requirement interact with the case (above) of not being able to compute for the full set at once?

---

Suppose I ask for node disjoint but am willing to settle for link disjoint. How do I express this?
It would be {node, but not strict} + {link, strict} But I see no way to express this.

---

If I say "not strict" can a PCE simply ignore me, or does it "do its best"? And do you define "best" for a group of LSPs? Fewest LSPs that are disjoint? Fewest points of non-disjointness across the group? 
Sounds like a few new OFs to me.

And how does the PCE report what is not quite as requested?

---

I think you have a new security consideration to include. There needs to be some authorisation associated with a group. Otherwise a "rogue" PCC can sabotage someone else's group by adding to it a strict request for an LSP that cannot possibly be disjoint. This would, as I understand it cause the whole group to be in error.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.