This is an important piece of work and there are a number of drafts dependent on it that will provide useful function. So we should definitely push forward to publication, but we also have to get this foundational document right otherwise we will struggle later.
I have some moderate-sized issues set out below. Most just need editorial work although a couple are more substantive technical points that may need changes or better explanation. Thanks for the work. Adrian --- I spent a lot of time trying to understand the relationship between the svec-list and the association group. This understanding was not enhanced by this document since the mention of svec is actually only in the RBNF in section 5.2.2. I think the only thing to do to make this clear is to add a specific section "Relationship with the SVEC List" and use that to explain how the two constructs relate. Now, I know that this document doesn't define any Association Types, and that might mean that you think you don't have to describe the relationship: "It is up to the documents that define individual Association Types," you may say. But I think you have to give some guidance in this document since you are defining a mechanism that is at last superficially similar. And certainly some (but not all) of the motivations in 3.1 might be achieved using SVEC. --- You don't make a lot of mention of RFC 6780. In fact, you only use it to define the association source. I think you need to describe how the PCEP Association maps to the RSVP-TE Association at least at a high level. (Again, I hear you saying that is an issue for the subsequent documents, but I think you have to give a framework. --- Why is there a different timeout for association state and LSP state? You have Association Timeout Interval: when a PCEP session is terminated, a PCC waits for this time period before deleting associations created by the PCEP peer. and The association are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exist as long as the LSP state. In case of PCEP session termination, the LSP state clean up SHOULD also take care of associations. Section 5.3 is not altogether clear and I suspect some of the procedures it describes are not defined in this document but are inherited from another document. --- 3.3 has A range of association identifier for each association-type are kept for the operator-configured associations. Dynamic associations MUST NOT use the association identifier from this range. What error code is used if a dynamic association breaks this rule? I can't see the behavior described. --- As far as I can see, the only reason you need the Operator-configured Association Range TLV is because you allow the Association Source to be set arbitrarily. But there is completely no value in doing that! An association is created by some element in the system and that element needs to be clearly identified. Thus the association ID is not globally unique, but is interpreted in the context of the association source. Now, when a new association is advertised by a PCEP speaker, it only has to fill in itself as the source and then it can choose an association ID freely according to its own configuration an without negotiation with its peers. --- Notwithstanding the previous point, I think there is a slew of error cases with the Operator-configured Association Range TLV that haven't described. The start+range for given type could be larger than 0xffffffff. Two ranges may overlap. The range could be zero. --- 5.1 R (Removal - 1 bit): when set, the requesting PCE peer requires the removal of an LSP from the association group. This flag is used for ASSOCIATION object in PCRpt and PCUpd message, the flag is ignored in other PCEP messages. What does R==0 signify? --- 5.1 Association type (2-byte): the association type (for example protection). The association type are defined in separate documents. You should delete this example as you have no firm evidence that there will be a protection association type. On the other hand, you should reference section 6.4. --- 5.1 Association Source: 4 or 16 bytes - An IPv4 or IPv6 address. This could be the IP address of the PCEP speaker that created a dynamic association, an operator configured IP address, or an IP address selected as per the local policy. The value such as 0.0.0.0 or ::/128 are acceptable. As per my previous comments, I'm not comfortable with a lot of this. If you use anything other than a local identifier (for creating an association) or the identifier used when the association was created (for modifying an existing association) then you have a recipe for complete chaos! It may be that what you want to do here is completely rational, but the explanation is foggy at best. Perhaps an approach is to describe this field as: Association Source: 4 or 16 bytes - An IPv4 or IPv6 address that provides scoping for the Association ID. Then, in the procedures, you can describe for the different cases (e.g., configured, dynamic, created, modified) how the value is assigned and what values are legal. You need to be pretty careful with what addresses are valid, but especially careful with v6 address. --- Nowhere is it clear whether an {Association ID, Association Source} must be unique or can be re-used with a different Association Type. If unique then what happens if a PCEP speaker uses a valid ID/Source pair but gets the Type wrong? Perhaps that would be Error-Value 6 "Association information mismatch". --- 5.2 Presumably a PCErr can also include the <association list>. --- 5.2.2 I should have thought that if an association list can be present on a PCReq it would also be returned on the PCRep (with interesting variants like "you can have it in these associations, but not in those", and possible need for an OF or two). --- 5.3 Presumably if the R bit is set and the LSP was not in the association, we act as though it had been and we had removed it? --- 6. It would be hugely wise to go through the document and replace each "TBD" with "TBDn" (for n=1....) so that IANA and the RFC editor can clearly tell which case is which. --- 7. Can I deduce things about customers, the services they have bought, and their relationships from the association information? - that would be a privacy concern. Can I deduce anything about the network from the association source ID? Note that privacy is not just about encrypting info in PCEP messages to stop outsiders snooping it; it is also about only revealing to your peers information that should be shared, and protecting access (e.g., through management tools) to private information. --- 8. Should I be able to see which associations are known about at a PCEP peer and which LSPs belong to them? Should I be able to find out which ranges are (nearly) depleted? --- You have used [I-D.ietf-pce-pceps] in a normative way. ==== Nits... --- A few references seem to be out of date. --- There are quite a few editorial nits which would be good to clean up before sending to the RFC editor. --- Section 5.2 needs a reference to RFC 5511 to give context to the encoding. > -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric > Sent: 01 February 2018 14:10 > To: pce@ietf.org > Subject: [Pce] WG LC of draft-ietf-pce-association-group > > Hi all, > > This message initiates a 2-week WG last call for > draft-ietf-pce-association-group-04. Please review and share your > feedback on the PCE mailing list. This LC will end on Thursday February, 15. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce