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. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
