Re: [Pce] WG LC of draft-ietf-pce-association-group

["Adrian Farrel" <[e-mail]>]

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:[e-mail]] On Behalf Of Julien Meuric
> Sent: 01 February 2018 14:10
> To: [e-mail]
> 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.