Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[Dhruv Dhody <[e-mail]>]

Hi Hooman,

Apologies! Missed replying to this email...

On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa)
<[e-mail]> wrote:
>
> Dear Chairs
>
>
>
> Looking at the wiki page there was a comment on the sr-p2mp-policy draft.
>
>
>
> draft-hsd-pce-sr-p2mp-policy
>
> 109; More work is needed - align to PCECC, text needs to aligned to the PCE WG style
>
>
>
> The authors took an action to setup a meeting and discuss the alignment with PCECC farther. The final outcome of this meeting was unanimous agreement, by all the authors/vendors on the draft, to go forward with ERO object.
>
>

As an individual I-D, it is up to the co-authors to decide the content
of the I-D.

The comment (and earlier discussions) was to make sure we maintain
consistency across all our documents that we produce. RFC 8283
describes the PCECC architecture, where the PCE needs to interact with
not only the head-end routers (the usual stateful/stateless PCE case)
but also with the egress and the internal P routers. The WG has just
sent the first PCECC extension for MPLS label allocation along the
path to the IESG. For other use cases such as SR/SRv6 SID allocation
as well as for the branch node in the P2MP LSP and Native-IP, all are
under the PCECC umbrella. So far all use cases where the PCE needs to
interact with other nodes beyond the ingress and provide instructions
to them are using PCECC architecture.

So when the PCE is interacting with the head end for SR P2MP Policy,
it can use the usual stateful PCE extensions but when the PCE is
interacting with the branch nodes and leaf nodes for replication
segment, we strongly feel it should be described under the PCECC
architecture. So you could use the ERO object for encoding the full
P2MP path (and SR P2MP Policy) when interacting with the root node.
But when interacting with other nodes, use the PCECC technique i.e. a
new CCI object type (which could be used with the ERO if needed). This
would help you to not reinvent things as well as maintain consistency.
To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only
and not the whole document. If you still disagree please list the
technical reason why so that the WG can evaluate them.

>
> The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath Information (ietf.org) for backup paths is the easiest and the most efficient way to address the programming of a replication segment on PCC from to the PCE.
>
>
>
> The authors would like to move forward with the adaptation call please. In addition the authors are open to discuss the ERO preference in an interim open session with the chairs.
>
>

The document has not been updated after 109, last we discussed this,
we found that the document needed more work because it does not follow
the way the PCEP extensions are usually defined. It follows a very
unusual format (e.g. section 5) at places. It is good to provide
examples but suggest it be done in a way that is more
readable. Please follow the RBNF notations when specifying PCEP
message changes (in a backward-compatible way). Some of your
co-authors have vast experience in writing documents in this WG, I
suggest taking their help. Hopefully, a more readable version will
help you get more reviews.

Hope this helps, and again accept our apologies for missing replying
to this email earlier.

Thanks!
Dhruv & Julien

>
> Regards
>
> Hooman
>
>
>
>