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

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 11 Jan 2017 13:44:35 +0000

This is start of a two week poll on making draft-litkowski-pce-association-diversity-01 a PCE working group document.
https://www.ietf.org/id/draft-litkowski-pce-association-diversity-01.txt

Please review the draft and send an email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reasons.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

The poll ends on Wednesday January 25.

Thanks,

Jon, JP and Julien

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 11 Jan 2017 16:13:40 +0100

Yes/support

Olivier

Le 11/01/2017 à 14:44, Jonathan Hardwick a écrit :
> Please review the draft and send an email to the list indicating “yes/support” or “no/do not support”.  If indicating no, please state your reasons.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.
>
>  
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 11 Jan 2017 13:01:53 -0500

Yes/Support

On 11 January 2017 at 10:13, Olivier Dugeon <[email-masked]>
wrote:

> Please review the draft and send an email to the list indicating
> “yes/support” or “no/do not support”.  If indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> Pce mailing [email-masked]://www.ietf.org/mailman/listinfo/pce
>
>
>

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Wed, 11 Jan 2017 18:09:47 +0000

Support.

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Wednesday, January 11, 2017 8:45 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Poll for adoption: draft-litkowski-pce-association-diversity

Thanks,

Jon, JP and Julien

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Wed, 11 Jan 2017 18:15:47 +0000

Yes/support

[banner12]

Siva Sivabalan
PRINCIPAL ENGINEER.ENGINEERING
[email-masked]<mailto:[email-masked]>
Tel: +1 613 254 3782

Cisco Systems, Inc.
2000 Innovation Drive
KANATA
K2K 3E8
Canada
cisco.com

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

From: Siva Sivabalan (msiva)
Sent: Wednesday, January 11, 2017 1:10 PM
To: 'Jonathan Hardwick' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Poll for adoption: draft-litkowski-pce-association-diversity

Support.

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Wednesday, January 11, 2017 8:45 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Poll for adoption: draft-litkowski-pce-association-diversity

Thanks,

Jon, JP and Julien

---

From: <[email-masked]>
Date: Wed, 11 Jan 2017 18:21:49 +0000

Support as author

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Wednesday, January 11, 2017 14:45
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Poll for adoption: draft-litkowski-pce-association-diversity

Thanks,

Jon, JP and Julien

_________________________________________________________________________________________________________________________

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.

---

From: Colby Barth <[email-masked]>
Date: Wed, 11 Jan 2017 22:06:36 +0000

support as co-author.

-colby

> On Jan 11, 2017, at 8:44 AM, Jonathan Hardwick <[email-masked]> wrote:
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 12 Jan 2017 07:36:34 +0000

Hi WG, Authors,

Yes/Support   (but I have some concerns, that can be addressed once the document is a WG document)

(1)    Strictness

a.       The document suggest local policies to decide the computation behavior, I would prefer to have normative text for better inter-operability. I think this point was also discussed during the IETF meeting.

b.      Also It would be helpful if we keep the proposal aligned to existing PCEP objects and mechanism

                                                               i.      SVEC Flags (which are strict) [RFC5440]

                                                             ii.      OF codes (which allow maximizing diversity, with no strictness guarantee) [draft-dhody-pce-of-diverse]

c.       I would propose following encoding change

                                                               i.      Single disjoint association type (instead of 4)

                                                             ii.      Add flags in DISJOINTNESS-INFORMATION-TLV for node, link, srlg (similar to SVEC - strict)

                                                            iii.      Add OF-Code also in the TLV

(2)    I am not sure about this text in the section 3 -
   o  Configuration: in case the PCC is performing the path computation
      but the PCE (without computation engine) is managing the LSP
      parameters, the PCE should add the disjoint-group within the
      PCUpdate message to communicate to the PCC the disjointness
      constraint.

*         I don't think the use of PCUpd in this way would be aligned to the Stateful PCE draft. Perhaps this needs to be discussed on its own.

(3)    Some text should be added to suggest how this would work along with the protection association draft [draft-ananthakrishnan-pce-stateful-path-protection]. IMHO both association group should be used together when we would like to specify the diversity requirement of the protection LSP. Some text could be added here.

Based on the discussion with authors, I can provide text if required.

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 11 January 2017 19:15
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Pce] Poll for adoption: draft-litkowski-pce-association-diversity

Thanks,

Jon, JP and Julien

---

From: <[email-masked]>
Date: Thu, 12 Jan 2017 09:02:43 +0000

Hi Dhruv,

Thanks for your support and comments. We will take care of them.
The first point that I want to highlight is about the choice of having 4 different association types.
This helps to ensure consistency in the requests and prevents two head ends to request a different disjoint type for the same group-id.

Brgds,

From: Dhruv Dhody [mailto:[email-masked]]
Sent: Thursday, January 12, 2017 08:37
To: Jonathan Hardwick; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Poll for adoption: draft-litkowski-pce-association-diversity

Hi WG, Authors,

(1)    Strictness

Regards,
Dhruv

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,

Jon, JP and Julien

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 12 Jan 2017 08:57:14 -0500

Yes/support.

Thanks,
Rakesh

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 14 Jan 2017 17:07:49 -0000

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