[Pce] Re: A review of draft-ietf-pce-state-sync-07

[Adrian Farrel <[e-mail]>]

Thanks, Haomian.

Lots of snipping, just leaving the conversations.

Cheers,
Adrian

> 1.
>
> However, I find the examples running through sections 1.2, 1.3, and 1.4 to
be quite 
> unnecessary. There is a feeling of "trying too hard" to prove that there
are uses for
> the protocol extensions described in the body of the document. I would
have been
> very happy with just one paragraph listing out a few of the possible use
cases.
>
> Further, section 4 (which seems to rework the examples in sections 1.2,
1.3, and 1.4)
> is not really an explanation of how the protocol extension works, but more
of a set
> of use cases. Again, this feels like it is trying to prove the value of
the extension. Do
> we really need it? It is such a simple protocol extension.

<Haomian> I would agree on this point. By reading through I understand how
to use the state sync, but it's too much to be included in the document. We
need to agree on 'how many percentage of the current text we should keep
here?' My personal suggestion is around 30%.

[AF] An option here, in order to make a smoother change, is to move examples
into an Appendix. Then there can be just a simple paragraph in section 1
enumerating the use cases and pointing to the Appendix. 
[AF] Section 4 is a different thing.

> 1.2 para 2
>
[snip]
>
<Haomian> I interpreted the content as, and we can simplify it. To update
once confirmed. 

OLD: 
when a PCE makes an update, it is the PCC that is in charge of reporting the
LSP status to all PCEs with any LSP parameter changes which brings
additional hops and delays in notifying the overall network of the LSP
parameter change.

NEW: 
when a PCE makes an update, it is the PCC that is in charge of reporting the
LSP status to all PCEs with such LSP parameter updates.

[AF] Better :-)

BEST:
when a PCE makes an update, the PCC is responsible for reporting the LSP
parameter updates all PCEs.

> All the figures in the document need numbers and titles. The text should
refer to them using <xref> rather than "the figure above" etc.
<Haomian> leave it to later version. 

[AF] OK

> I'm confused by the example given in 1.2. LSP1 is under the control of
PCE1, 
> so any changes that are made are made with the direct instruction from
PCE1.
> Therefore, it is not necessary to wait for the change to be reported by
PCC1
> - PCE2 can be notified of the intended change. Surely that would be more
>   efficient. (Yes, that would only be possible if there is a session
between
>   the PCEs.)
>
> Additionally, when the change is made in the network, it seems unlikely to
me
> that PCC1 would be aware that it is LSP2 that has had its resources
reduced
> because PCC1 does not know about the existence of LSP2. However, the
> network nodes servicing LSP2 would know about this and so it would be
> reported to PCC2 which can report it direct to PCE2.
>
> (Note that this does not take anything away from the proposed protocol 
> extension. It is just a confusing example.)


<Haomian> I don't see anything wrong about the current text - the confusion
comes from too many alternative way to do the sync and people may have
different intuition. I would propose to remove the descriptions about LSP2,
just saying PCC1 reporting the update of LSP1 to PCE2 is slower than sync it
from PCE1 to PCE2, does it work better?

[AF] I agree with saying that "PCC1 reporting the update of LSP1 to PCE2 is
slower than sync it from PCE1 to PCE2"

> 1.3
>
>   By considering a network with
>   multiple PCCs and implementing multiple stateful PCEs for redundancy
>   purpose, there is no guarantee that at any time all the PCCs delegate
>   their LSPs to the same PCE.
>
> There is something not quite right about this sentence. Is there a 'not'
> missing, such as...
>
>   By considering a network with
>   multiple PCCs and implementing multiple stateful PCEs for redundancy
>   purpose, there is no guarantee that at any time all the PCCs will not
>   delegate their LSPs to the same PCE.
>
> The word 'preemption' is used later in the section, as well.

<Haomian> I am having different understanding, perhaps the following. (BTW I
am not a fan of double negative) 
NEW: 
   By considering a network with
   multiple PCCs and implementing multiple stateful PCEs for redundancy
   purpose, it is not likely that all PCCs delegate their LSPs to the same
PCE.

[AF] That's better.

> 1.3. The figures on page 7, it is slightly odd that you have named the
> destination/egress of the LSPs as PCCs. It is true that they might be
> PCCs for other LSPs, but is that relevant?
<Haomian> How about change the arrows from uni-directional to
bi-directional?

[AF] Hmmm. Even so, does that mean just that the LSPs are bidirectional? I
think you need to have a pair of unidirectional LSPs for this to be the
case.

> 2.2
>
>   To provide
>   the best efficiency, an LSP association constraint-based computation
>   requires that a single PCE performs the path computation for all LSPs
>   in the association group.
>
> I don't agree with this as stated.
>
> I do agree that it can be more optimal, and that there are some algorithms
> that compute two paths at the same time, but it is also possible to
construct
> "split brain" solutions that work fine, if a little more slowly and with
more
> information exchange.
>
> Further, not all LSP associations need knowledge of the path of one LSP to
> establish the other LSPs.
<Haomian>Following changes proposed: 

OLD: 
To provide the best efficiency, an LSP association constraint-based
computation requires that a single PCE performs the path computation for all
LSPs in the association group.

NEW: 
To achieve better efficiency, an LSP association constraint-based
computation MAY require that a single PCE performs the path computation for
all LSPs in the association group.

[AF] Good. But s/MAY/may/

> In 2.2 I am not clear whether PCE2 is transferring delegation to PCE1 or
just asking
> PCE1 to perform a computation. I think that PCE2 is allowed to ask anyone
for help
> performing a computation, but the issue of delegation could be sensitive -
the PCC 
> has delegated to PCE2: does that mean that the PCC is giving permission
for the
> delegation to be passed on? Could this be sensitive because PCE2 might be
in a 
> domain that the PCC doesn't trust? Or do you assume that, because the PCC
has
> a session with both PCEs, it trusts them equally?
>
> I did find 3.5 about "sub-delegation" and I think this is relevant.

<Haomian> We need some consensus on this comment in section 2.2
(primary-secondary relationship): I assume that PCC has a session with both
primary/secondary PCEs and delegate the LSP to primary PCE, and such
delegation would be migrated to secondary PCE in case there is a need (may
because of the failure of primary PCE or just a policy). We can tweak the
text after we are on the same page, proposal are welcome.

[AF] It's a triangular relationship, isn't it. This function depends on the
PCC having a relationship between both PCEs, the PCEs having a relationship,
*and* each PCE knows that the PCC has a relationship with the other PCE.
[AF] To reiterate:
[AF] - The PCC is free to delegate as it wishes and to change the
delegation.
[AF] - The PCEs are not free to "simply" exchange delegation because they
can't know that they are allowed to. Well, I suppose that is a network
policy?

3.5

   If the highest priority PCE is failing or if the state-sync session
   between the local PCE and the highest priority PCE failed, the local
   PCE MAY decide to delegate the LSP to the next highest priority PCE
   or to take back control of the LSP.  It is a local policy decision.

What does "is failing" mean? How can one PCE know that another is failing?

<Haomian> I don't think the PCE knows the failure automatically, it's more
likely to be manually configured.

[AF] Right. So the point would be that the operator may decide to instruct a
switch-over.

> 3.5.1
>
>   A PCE SHOULD NOT compute a path
>   using an association-group constraint if it has delegation for only a
>   subset of LSPs in the association-group
>
> It is unclear to me that a PCE can know this. In some cases, the
association is
> for a known number of LSPs (e.g., bidirectional), but in other cases there
can
> be a large number of LSPs in the group (e.g., VN), and the group can be
added
> to at any time.

<Haomian>We need to check the motivation on section 3.5.1. I would reword
this sentence as "A PCE SHOULD ONLY compute a path using an
association-group constraint if it has delegation for all of LSPs in the
association-group". The PCE know this by checking the LSP identifier to see
if they are correctly delegated.

[AF] Hmmm.
[AF] s/SHOULD ONLY/SHOULD only/  
[AF] But I don't think this addresses my point. For some association groups,
it is possible to know when you have the complete set of LSPs. But other
association groups are open-ended. How can you know when you have them all
unless you have information from the creator of the group?

> 6.
>
>   The list of speakers within the PCEP-PATH-VECTOR TLV MUST be ordered.
>
> Ah, but what order? 
>
>   When sending a PCEP message (PCRpt, PCUpd, or PCInitiate), a PCEP
>   Speaker MAY add the PCEP-PATH-VECTOR TLV with a PCEP-SPEAKER-
>   INFORMATION containing its own information.
>
> Addition is presumably in a specific order. "add to the end of the list"?
>
> You do say "append" at the bottom of the paragraph, so I think it is 
> clear what you intend: you just need to bring it out more clearly.

<Haomian> I am confused. Does it mean "the PCEP speaker MAY append a new
PCEP-SPEAKER-INFORMATION containing its own information at the end of the
TLV"?

[AF] This is how I read it.