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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
