Hi, Adrian,
Thank you for the question. A short answe to your question would be:
we are following the same logic as how we handle the LSP delete/update as
described in the stateful PCE base draft.
To explain a bit more: in the version we are prensenting, both the PCE
(with delegation enabled or initiation capability) and the PCC can create
association groups, so we need a way to delete/update the association
membership information for a LSP if it is PCE created. There are two options:
1) The one you propose below;
2) The one we use, by using a flag;
The advantage of this, as i can think of, is: instead of resending the
remaining association groups which are still valid, in order to get rid of
some, we just using a R flag to delete what association. So, it is an
incremental change. As for PCC-created association, it can delete itself and
report the update to the stateful PCE.
As for the error handling part, I think you have made a good point. It is
indeed somthing that we are discussing and will be included in the next
version.
Regards,
Xian & Ina
________________________________________
发件人: Pce [[email protected]] 代表 Adrian Farrel [[email protected]]
发送时间: 2015年7月23日 20:31
收件人: Ina Minei
抄送: [email protected]
主题: [Pce] More on draft-minei-pce-association-group
Hi Ina,
In the interest of time, moved from mic to list...
I'm struggling with the semantics of the Association object is used.
In signaling, when I mention an LSP I mention all of the Associations that are
relevant. If I mention the LSP again with a different set of Associations, this
set replaces the previous set.
Now, here you have a different semantic with the R-bit. This means that the set
of Associations for an LSP is the sum of all reported Associations, and they
only go away when the R-bit is set.
I think you have done this in order to allow for multiple PCCs/PCEs reporting
Associations.
But you have created a state synchronisation problem because the addition (and
more importantly the removal) of an Association is not a confirmed operation.
Thus, if the PCEP session goes down, we aren't sure whether the other end knows
about the Association state we think we sent it. This is OK for adding
Associations because we can re-send them. For removal of Associations we are now
in a mess and forced to retain removal state until we are sure our peer has
heard us. That seems icky. Have I missed something?
An alternative is to go to the signaling model and say that Associations
*in*PCEP* must be reported by the node that created them and that all
Associations created by a node must be reported in the same message. This allows
for recovery.
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
