Hi John,
<snip>
> > ***************
> > *** 507,513 ****
> > --- 558,573 ----
> >
> >
> > In some cases, a stateful PCE can request the PCC to allocate any
> > + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > binding value. It instructs the PCC by sending a PCUpd message
> > + ^^^^^^^^^^^^^
> > + I don't understand what that means. My *guess* is that you mean
> > + the PCE is just saying "hey PCC, please allocate a binding value
> > + and tell me what it is". Is that right? If so I think this
> > + could be worded even more clearly, perhaps "a stateful PCE may
> > + want to request that the PCE allocate a binding value of the PCE's
> > + own choosing"?
> > +
> >
> > [Dhruv]: It should be PCC's own choosing.
>
> Were you just correcting my comment (to say I should have written “PCC”
> the latter two times, I agree, my mistake), or was your point also to say
> that yes, my guess is correct? If the latter, then as I mentioned, I’d
> appreciate having the wording improved.
>
>
[Dhruv]: I was correcting your suggested text (sorry for not being clear).
I agree that clarifying text is a good idea.
> > <snip>
> > ***************
> > *** 655,660 ****
> > --- 742,758 ----
> > * Send a PCErr message with Error-Type=19 (Invalid Operation)
> and
> > Error-Value=16 (Attempted PCECC operations when PCECC
> > capability was not advertised)
> > +
> > + You need to update your reference to point to RFC 9050. You should
> > + then either reference §5.4 and NOT copy-and-paste the relevant text,
> > + or you should (less desirably, IMO) update your copy-and-paste to
> > + the text published with RFC 9050. Notably, RFC 9050 covers the case
> > + of a legacy PCEP speaker, whereas the text in this spec doesn't.
> > +
> > + IMO since RFC 9050 already specifies what to do when the capability
> > + isn't exchanged, there is no need to say anything at all in this
> > + document, so unless you have a compelling reason (what?) to keep it,
> > + please remove this bullet and its two sub-bullets.
> >
> > * Terminate the PCEP session
> >
> >
> >
> > [Dhruv]: The only reason to include this text is for "P=1 in the LSP
> object" i.e. the presence of the LSP object with P flag set is to be
> considered as a PCECC operation, which would not be the case in RFC9050.
>
> I see, thanks. In that case, then I guess the copy-paste needs to be
> updated to follow the text in 9050, or if that doesn’t work for some reason
> I’ve overlooked, in any case the text needs to be updated to cover the case
> of a legacy speaker.
>
>
[Dhruv]: Agree.
> > ***************
> > *** 745,754 ****
> > [RFC8281] and [RFC8664] are applicable to this specification. No
> > additional security measure is required.
> >
> > ! As described [RFC8664], SR allows a network controller to
> instantiate
> > and control paths in the network. A rogue PCE can manipulate
> binding
> > SID allocations to move traffic around for some other LSP that uses
> > BSID in its SR-ERO.
> >
> > Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
> > only be activated on authenticated and encrypted sessions across
> PCEs
> > --- 843,857 ----
> > [RFC8281] and [RFC8664] are applicable to this specification. No
> > additional security measure is required.
> >
> > ! As described in [RFC8664], SR allows a network controller to
> instantiate
> > and control paths in the network. A rogue PCE can manipulate
> binding
> > SID allocations to move traffic around for some other LSP that uses
> > BSID in its SR-ERO.
> > +
> > + Try as I might, I'm not able to figure out what, specifically, the
> above
> > + sentence (that begins "a rogue PCE") means. I mean, I get it, a rogue
> > + PCE can misdirect traffic. Beyond that, can you help me understand
> what
> > + you meant to convey here?
> >
> > [Dhruv]: IMHO it highlights how this new capability of "allocating
> binding SID" can be exploited by a rogue PCE to misdirect traffic. Path
> {A, B, BSID_1} can be misdirected just by assigning the BSID_1 value to a
> different LSP making it a lot easier (and harder to detect).
>
> I think it would be helpful to add something concrete like that.
>
>
[Dhruv]: I agree.
> > Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
> > only be activated on authenticated and encrypted sessions across
> PCEs
> > ***************
> > *** 773,778 ****
> > --- 876,889 ----
> >
> > The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
> > include policy configuration for binding label/SID allocation.
> > +
> > + It looks like pcep-yang expired a couple months ago, but I think
> > + that's just an oversight and doesn't reflect the WG abandoning
> > + the work. Is there any intention on the part of the WG, to
> > + extend it as described? My understanding is that yes, the WG does
> > + intend to do this -- in that case I think this section would be
> > + stronger if you indicated that, something like "The PCEP YANG module
> > + will be extended..." instead of "could be".
> >
> >
> >
> > [Dhruv]: This one is my fault. It is on my to-do list to update.
>
> OK, thanks. If the WG has consensus that the YANG module will be extended
> as described, I think making the suggested change might help avoid
> questions during IESG review.
>
>
[Dhruv]: Sure!
<snip>
Cheng is holding the pen for this I-D. It's a holiday week in China, so
let's give him some time to respond.
Thanks!
Dhruv
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
