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:[email protected]]
Sent: Saturday, January 14, 2017 18:08
To: 'Jonathan Hardwick'; [email protected]
Cc: [email protected]; [email protected]
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.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
