Hi PCE Chairs,
As one of the authors, I support WG adoption of the current draft.
Hi Andrew,
Thanks for your valuable input, let me reply.
1. It would be up to the head-end to decide what CP is active, so I would say
that we probably do not need to explicitly state in this draft that only one CP
must be active. But should explicitly state how an active CP is distinguished
from non-active CP in terms of PCEP flags.
2. Agree, we should reference draft-sivabalan-pce-binding-label-sid, I would
say that it's necessary to support binding-label-sid in order to support the
current draft, because it's unpractical to have an SR Policy without a binding
SID.
3. Agree, we should reference draft-koldychev-pce-multipath. However, it should
not be necessary to support draft-koldychev-pce-multipath in order to support
the current draft though. But you would only be able to have a single
segment-list per CP without supporting draft-koldychev-pce-multipath.
4. I agree with your concerns, we can wait for wider input/consensus and decide
what to do about this section.
Thanks,
Mike.
-----Original Message-----
From: Pce <pce-boun...@ietf.org> On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Monday, June 8, 2020 12:05 PM
To: pce@ietf.org
Subject: Re: [Pce] WG adoption poll for
draft-barth-pce-segment-routing-policy-cp-06
Hi PCE Chairs and WG
A few questions/comments regarding draft-barth-pce-segment-routing-policy-cp-06:
1. draft-ietf-spring-segment-routing-policy states that only a single
candidate path can be active within an SR Policy. While we wouldn't want to
repeat all the text in the PCEP document that it's in the spring document and
focus more on the encoding of signalling, should PCEP comment on this (only 1
active CP in an SR Policy association group)?
2. Binding SID is an important attribute of SR Policy, and for PCEP that is
currently described independently in draft-sivabalan-pce-binding-label-sid (as
it should be) - should draft-barth-pce-segment-routing-policy-cp-06 make a
point to reference this? For an implementation of
draft-barth-pce-segment-routing-policy-cp, must it support
draft-sivabalan-pce-binding-label-sid ?
3. Similar to previous point, draft-barth-pce-segment-routing-policy-cp-06 has
editor comments regarding support of multiple SID lists to be described in
another document. draft-koldychev-pce-multipath describes a mechanism for this.
Should draft-barth-pce-segment-routing-policy-cp make a reference to this? For
an implementation of draft-barth-pce-segment-routing-policy-cp, must it support
draft-koldychev-pce-multipath ?
4. Section 4.3 leaves me confused. The term 'sub-candidate path' is not used
anywhere else to my knowledge, and the concept of ECMP/UCMP makes it sound like
the behaviour of multiple SID Lists to me, since a single candidate path will
W-ECMP across multiple SID Lists. The use case requirement for encoding
objective/constraints was discussed in the past, in Montreal if I recall, to
allow the ability to tell PCE different constraints (ex: path1 take red plane,
path2 take blue plane) and ECMP across it. I think this is certainly a valid
use case, but it's not clear to me from this section how that's achieved within
PCEP encoding and how that fits into the SR Policy model. How does a
sub-candidate path differ from a SID list? Or are they the same? Then why all
the language about PCEP tunnel and candidate path? Or is the intent to
basically signal multiple candidate paths with the intent to ECMP across the
SID Lists contained within them? I get a slight impression that there's a
either (intentionally or unintentionally) potentially a logical new containment
introduced in the SR Policy model in order to encode optimization
objective/constraints for PCE. The language of mapping sub-candidate paths each
to a PCEP Tunnel also leaves me confused since a candidate path is a PCEP
Tunnel as described in section 4.1. Some additional clarification, diagrams or
examples in this section is needed I think.
Regarding the adoption call:
Overall I think the draft should be adopted by the PCE WG. Having PCE
instantiate and compute paths for a Candidate path, with full awareness of the
context of an SR Policy is a natural fit. The existing implementations of SR
Policy via BGP shows that SR Policy instantiation from a controller to the
network is important, however in some deployments and platforms using PCEP
would be a better fit than BGP. Using PCEP also helps ease the feedback
complexity in reporting state back to the controller, felt by BGP. With the
exception of section 4.3 to me, I think the document reflects the overall
architecture and model described in draft-ietf-spring-segment-routing-policy
and follows a sensible encoding model in PCEP in its mappings of
PLSP-ID/Candidate path and use of association. I think section 4.3 need to be
evaluated and discussed in more detail - whether I think it should be before or
after adoption I'll leave up to the WG consensus on this section ...
Thanks
Andrew
On 2020-06-07, 3:46 AM, "Pce on behalf of Dhruv Dhody" <pce-boun...@ietf.org
on behalf of dhruv.i...@gmail.com> wrote:
Hi WG,
This email begins the WG adoption poll for
draft-barth-pce-segment-routing-policy-cp-06.
https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/
Should this draft be adopted by the PCE WG? Please state your reasons
- Why / Why not? What needs to be fixed before or after adoption? Are
you willing to work on this draft? Review comments should be posted to
the list.
This adoption poll will end on 22nd June 2020.
Thanks!
Dhruv & Julien
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
