[Pce] Update to PCEP-LS

[Dhruv Dhody <[e-mail]>]

Hi WG, 

Ramon provided comments on the PCEP-LS based on his implementation experience. Thanks Ramon. 
There are some changes in the draft - https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ 

* Clarification of TLV format 
* Protocol-ID for Unspecified, PCEP-LS and Reserved (0) added

The email discussion is included below - 

Regards,
Dhruv

>Hi Dhruv, Young
>
>I have started to implement a subset of PCEPLS and -- still lacking an
>in-depth analysis -- I have a couple of questions (sorry if they are
>obvious):
>
>- How do you withdraw a link / node (as in MP_UNREACH_NLRI). Section
>9.2.10 refers to remove an attribute (I am still trying to understand the 
>case where I need to remove an attribute, in our use cases, we announce a 
>link, update its attributes, and we may withdraw it, but it is strange to 
>remove an attribute. Maybe it will come more natural when we get more 
>insight on incremental updates). I considered sending an LS object with all 
>the attributes following Sect 9.2.10 but I am not convinced. I was expecting 
>something like a flag in the LS object where I need to indicate e.g. the 
>link descriptors and it conveys end-of-lifetime for the link/node.
>

[Dhruv]: Yes you are right, we have the R flag in LS object. 

   o  R (Remove - 1 bit): On LSRpt messages the R Flag indicates that
      the node/link/prefix has been removed from the PCC and the PCE
      SHOULD remove from its database.  Upon receiving an LS Report with
      the R Flag set to 1, the PCE SHOULD remove all state for the
      node/link/prefix identified by the LS Identifiers from its
      database.

And only to remove an attribute, we use - 

9.2.10.  Removal of an Attribute

   One of a key objective of PCEP-LS is to encode and carry only the
   impacted attributes of a Node, a Link or a Prefix.  To accommodate
   this requirement, incase of a removal of an attribute, the sub-TLV
   MUST be included with no 'value' field and length=0 to indicate that
   the attribute is removed.  On receiving a sub-TLV with zero length,
   the receiver removes the attribute from the database.

>- Much like in BGPLS I am lacking the ability to know the switching 
>capability of a link (generalizing, ISCD / IACD).  Is this intentional, 
>focusing on packet switching?

[Dhruv]: This is covered in - https://tools.ietf.org/html/draft-lee-pce-pcep-ls-optical-00

[Ramon]: Thanks Dhruv, that was useful. Thanks for the pointer to optical (works for us, but I was hoping to find ISCD Swcap etc. in a wider GMPLS aware context ;)
In an "ideal world" I would have assumed pcepls  pcepls-gmpls [or even intergated both, but it was not the case with RFC5440, and pcepls-optical but IMHO you can leave it as is :-)

>- A small nit for me (ignore) is in RBNF I like to see <foo-list> ::= 
><foo> [ <foo-list> ]
>
>so seeing <ls-report-list> ::= <LS> [ <ls-report-list> ] has been 
>"mentally" translated to
>
><ls-list> ::= <LS> [ <ls-list> ]
><ls-report-list> ::= <ls-list>
>
>(I am aware both are equivalent and this is so common in RFC that I just 
>deal with it...)

[Dhruv]: As you noted we have a mixed bad, I would like to keep it as it is for now! 

[Ramon]: Sure,no need to change now. It may be likely that other objects are added in the future (?)


>- Typo Sect. 9.2.2  Tho allow -> To allow

[Dhruv]: Ack

>- I would be explicit in quoting RFC5440 in the TLV format and, more 
>importantly, I would clearly state that the same TLV format is used for 
>sub-TLVs (unless I missed it) specially with potential confusion reusing 
>BGP-LS ?
>
>- In page 23 the table mentions BGP-LS TLV but only mentions the BGP_LS 
>TLV for a few of them? On that note... It is fine either way, but I am 
>curious on why not aligning with the actual values as well?

[Dhruv]: We decided to point to IS-IS TLV when that exist, and for new TLVs that were newly created in BGP-LS to point there. 
We could point to BGP-LS for all, but BGP-LS would itself point to IS-IS adding one more indirection :)

[Ramon]: Not a big deal, alternatively you could consider putting the BGP-LS TLV id for all, so  from needing to consult IS-IS refs :)

[Dhruv]: I wish there was more space in the table for me to do that! 

> OTOH, this is not addressing why not pick the same values of TLVs as BGP has? (I am fine with any value, but this question is a FAQ)

[Dhruv]: With hindsight, yes that could have been done. But at the same time since the padding/length rules are different between BGP and PCEP, one must encode/decode these TLVs independently and  maintaining an loose link between them is better. 

>
>- Personally, I would like a protocol_id of 0, unspecified, because I am 
>exporting a TED that is acutally constructed by multiple mechanisms.

[Dhruv]: Correct, I have updated 0 as reserved (similar to BGP-LS). Is that okay? 

[Ramon]: I was thinking more of a "I don't care" value instead of a "reserved" one (which I cannot use). But since BGP-LS has a "reserved" better stick to it. In other words, I may need to advertise a TED to a p-PCE where the child PCE has constructed the TED from multiple sources without keeping track of it.
Additionally, would you include a "pcep-ls" identifier? since you are considering bpg-ls, why not pcep-ls? I am guessing recursive architectures or even the parent PCE advertising the TED to a third party, with the p-PCE having learnt the topology 

[Dhruv]: Added - Unspecified, PCEP-LS, Reserved. 

>
>
>Surely more will come later ;)
>
>Best regards
>Ramon