[Pce] 答复: 答复: Working Group last call on draft-ietf-pce-stateful-hpce-06
Hi, Daniel, Thank you for the updating, the previous comments are ALL addressed. Best wishes, Haomian -邮件原件- 发件人: Daniel King [mailto:d...@danielking.net] 代表 dan...@olddog.co.uk 发送时间: 2019年6月10日 20:11 收件人: Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) 抄送: pce@ietf.org 主题: RE: [Pce] 答复: Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi Haomian, Thank you again for the review and suggestions. We believe we have addressed your comments. BR, Dan. -Original Message- From: Pce On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) Sent: 01 April 2019 08:39 To: adr...@olddog.co.uk; pce@ietf.org Subject: [Pce] 答复: Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi, WG, I have read this document and believe this work is very useful. Stateful H-PCE will enable a more efficient way to do the computation with a group of PCEs. The document is in a good shape as well. I support to move forward on this document, some minor comments are provided to be fixed after the LC: - The page number in ToC is not consistent, maybe an update on word would be needed; - PCEP stateful extension in RFC8231, and PCEP initiation extension in RFC8281, are usually considered as two separate works. Given the fact we have merged the gmpls extension with two features, it is reasonable to have these two features in the h-pce work as well. I noticed there is corresponding descriptions in section 3.3, and I think it would be useful if one sentence can be summarized in the abstract. OLD: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). NEW: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). Initialize the result of path computation from PCE is also helpful for the PCC to gracefully establish the computed LSP. - As mentioned in IETF 104 PCE WG session (draft-ietf-pce-enhanced-errors), error handling issues need to be mentioned for inter-pce works, and this work exactly fits into the scope. It is suggested to add one small section about this. How about the following? 7.7. Error Handling between PCEs Error types specified in PCEP should be properly propagate between parent and child PCEs. The propagation, notification and criticality level defined in [I-D. ietf-pce-enhanced-errors] are recommended. - The idnits report an unused reference 'pcep-yang', probably because of the line in section 7.2 for citation is not properly broken in the middle. Editing will be helpful to fix it. We are looking forward to see the improvement after the WG LC, thank you. Best wishes, Haomian -邮件原件- 发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Adrian Farrel 发送时间: 2019年3月14日 6:01 收件人: pce@ietf.org 主题: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi working group, This email starts a working group last call for draft-ietf-pce-stateful-hpce-06. I would like to hear messages of support or concern about this draft. If you support its progression towards publication as an RFC, please let us know that you have read the latest revision, and explain why you think the work is important. Indications of implementation would also be welcome - although this document is informational, I believe some people may have built stateful hierarchical PCEs for experimentation or deployment. If you are opposed to the progression or have concerns please articulate them. As always, review comments and nits are most welcome. Because of the effort that is going in to preparing for IETF-104 and because of the time spent away, this last call will run for three weeks and end on April 4th. Thanks, Adrian ___ 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
[Pce] Comments on draft-dhs-spring-pce-sr-p2mp-policy
Hi authors,
I have the following comments on your draft:
1. Support for multiple candidate-paths, segment-list, etc.
The procedures defined here are not aligned to those in
“draft-barth-pce-segment-routing-policy-cp” for unicast SR policies– for
example:
1. Ability to instantiate multiple candidate path, or
2. Using SR Candidate Path Association Group to associate the multiple
candidate-path(s) for the same SR policy, or
3. Ability of having multiple Segment-list(s) per endpoint (with
equal/unequal weights)
What are your plans to align to draft-barth-pce-segment-routing-policy-cp?
2. Path selection when instantiating using different protocols (e.g. BGP SRTE,
PCEP, or NETCONG/config)
For unicast SR policies, it is possible have multiple candidate paths (for the
same SR policy) instantiated via BGP, PCEP, or NETCONG/config. In such case, a
preference-based selection and tie-breaking criteria to select from amongst the
candidate path(s) was defined, but those cannot be applied using approach
defined in this ID.
Any plans to address this?
3. SR-IPV4-P2MP-LSP-IDENTIFIER TLV, LSP-ID and P2MP-ID
If 1) and 2) above are sorted out, I believe LSP-ID would not be needed and can
be removed.
I prefer to completely replace P2MP-ID by “color” to 1) aligned to the ‘color’
for used in unicast SR Policies, and 2) avoid the confusion since P2MP ID is
set by the ingress in RSVP-TE – noting `color` is usually carried in service
routes as ext-com so that the ingress can use it as a service selector.
4. New SR-P2MP-CCI Object:
I understand you are inheriting this object from
“draft-ietf-pce-pcep-extension-for-pce-controller-00”, however, it is not clear
to me how one can program a P2MP Tree-SID (e.g. having an In-label
cross-connected to multiple next-hops – where each next-hop having its own
label stack)?
If the assumption is multiple CCI Objects (Type MPLS Label) will be downloaded
for each out-label in the stack? If so, what defines the position in the label
of the stack? How can I specify an out-label stack with repeated same label,
e.g. next-hop=NH, and out-label-stack-{L1, L1, L1}? Noting, could downloading
the same SR-P2MP-CCI with same outgoing label multiple times be interpreted as
redundant?
5. Programing new/reopt p2mp SR LSP
When setting up the LSPs, a sequential order of visiting nodes starting from
egress back ingress is desirable (for example see Figure 2: Basic PCECC LSP
setup in draft-ietf-pce-pcep-extension-for-pce-controller).. I did not see it
explicitly highlighted in your draft.
Regards,
Tarek
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Review of draft-ietf-pce-stateful-hpce
Thanks, Dan, I'm checking the diffs and then I'll do the shepherd write-up and move the document along. Best, Adrian -Original Message- From: Daniel King On Behalf Of dan...@olddog.co.uk Sent: 10 June 2019 13:21 To: adr...@olddog.co.uk Cc: pce@ietf.org Subject: RE: [Pce] Review of draft-ietf-pce-stateful-hpce Hi Document Shepherd, Thank you for your detailed review, comments and suggested text. The authors believe we have addressed all the open issue with the last two revisions of the I-D. If you would be so kind as to scan through the changes it would be very much appreciated. Please also find a number of comments inline below (DK>>). BR, Dan. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Review of draft-ietf-pce-stateful-hpce
Hi Document Shepherd, Thank you for your detailed review, comments and suggested text. The authors believe we have addressed all the open issue with the last two revisions of the I-D. If you would be so kind as to scan through the changes it would be very much appreciated. Please also find a number of comments inline below (DK>>). BR, Dan. -Original Message- From: Pce On Behalf Of Adrian Farrel Sent: 25 March 2019 16:32 To: draft-ietf-pce-stateful-h...@ietf.org Cc: pce@ietf.org Subject: [Pce] Review of draft-ietf-pce-stateful-hpce Hi, Good afternoon. My name is Adrian and I'll be your Document Shepherd for this journey. As this draft is progressing through working group last call, I thought I would do my review now and save a little time later. These comments may seem a little negative, but I hope you can address them with small changes. Thanks, Adrian === Abstract s/deployment of Stateful PCE(s)/deployment of Stateful PCEs/ DK>> Done --- Section 1 para 1 needs a reference to 5440 DK>> Done --- 1. s/for stateful PCE(s) in/for stateful PCEs in the/ DK>> Done --- 1. The initial section of the document focuses on end to end (E2E) inter-domain TE LSP. Section 3.3.1 describe the operations for the Per Domain LSP that could be stitched. Maybe... Sections 3.1 and 3.2 focus on end to end (E2E) inter-domain TE LSPa. Section 3.3.1 describes the operations for stitching Per Domain LSPs. DK>> Done --- I am not certain that you need to use upper case terms in this document. I found "SHOULD" in sections 6 and 7.2, and "MAY" twice in seciton 3.1 and once in section 3.3.1. Also "RECOMMENDED" in section 6. Is this really appropriate in a document that is describing an approach, not specifying bits on the wire or implementation behavior? That would allow you to dispose of section 1.1 and the two references. DK>> Done --- Section 3 While the terms PE and CE are defined and used unambiguously, I suspect that they will cause some confusion because they are such well known terms in networking. DK>> Done. We now use C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE (EP-EC). --- 3. All PCE types herein (i.e., PE or CE) are assumed to be 'stateful PCE'. Is it not plausible to have a stateless C-PCE working with a stateful P-PCE? I think that the relationship of child to parent is similar to the relationship of PCC to PCE, but when we talk about a stateful PCE we don't also talk about a stateful PCC. So when you say that the C-PCE must be stateful, you are necessarily talking about its relationship with its PCCs. If you are determined to limit the scope of this document to PCE hierarchies where both the parent and child are stateful (you are allowed to make this choice if that's what the WG wants) then you need to make this clear in the Abstract and Introduction. DK>> Done --- Am I confused about delegation? You have... The P-PCE has no information about the content of the child domains. Clearly the C-PCE will report the path of the LSP (segment) that crosses the domain for which it is responsible, but how can the P-PCE make any change to that LSP without visibility into the child domain? But you go on to talk about delegation as if it could work: such as... LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs When you draw the similarity between PCC-PCE and C-PCE-P-PCE delegation as... Note that this hierarchy is recursive and thus a Label Switching Router (LSR), as a PCC could delegate the control to a PCE, which may delegate to its parent, which may further delegate it to its parent (if it exist or needed). Similarly update operations could also be applied recursively. . I think that you miss that the PCC and PCE can both see the TED, but the C-PCE and P-PCE have very different visibility into the domain. DK>> Done. We clarified the text. --- 3. Just clarity... OLD [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE capability TLV that should be used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the stateful PCE capability TLV. The presence of both TLVs represent the support for stateful H-PCE operations as described in this document. NEW [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV that is used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the Stateful PCE Capability TLV used in the OPEN message to indicate stateful support. The presence of both TLVs in an OPEN message indicates the support for stateful H-PCE operations as described in this document. END DK>> Done. Thanks. --- 3. I feel that this paragraph is confusing. I think the referenced draft also needs some work on the terms stateful and synchronization, but we can focus on the document at hand. OLD [I-D.litkowski-pce-state-sync] describes the procedures to allow a
Re: [Pce] 答复: Working Group last call on draft-ietf-pce-stateful-hpce-06
Hi Haomian, Thank you again for the review and suggestions. We believe we have addressed your comments. BR, Dan. -Original Message- From: Pce On Behalf Of Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) Sent: 01 April 2019 08:39 To: adr...@olddog.co.uk; pce@ietf.org Subject: [Pce] 答复: Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi, WG, I have read this document and believe this work is very useful. Stateful H-PCE will enable a more efficient way to do the computation with a group of PCEs. The document is in a good shape as well. I support to move forward on this document, some minor comments are provided to be fixed after the LC: - The page number in ToC is not consistent, maybe an update on word would be needed; - PCEP stateful extension in RFC8231, and PCEP initiation extension in RFC8281, are usually considered as two separate works. Given the fact we have merged the gmpls extension with two features, it is reasonable to have these two features in the h-pce work as well. I noticed there is corresponding descriptions in section 3.3, and I think it would be useful if one sentence can be summarized in the abstract. OLD: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). NEW: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). Initialize the result of path computation from PCE is also helpful for the PCC to gracefully establish the computed LSP. - As mentioned in IETF 104 PCE WG session (draft-ietf-pce-enhanced-errors), error handling issues need to be mentioned for inter-pce works, and this work exactly fits into the scope. It is suggested to add one small section about this. How about the following? 7.7. Error Handling between PCEs Error types specified in PCEP should be properly propagate between parent and child PCEs. The propagation, notification and criticality level defined in [I-D. ietf-pce-enhanced-errors] are recommended. - The idnits report an unused reference 'pcep-yang', probably because of the line in section 7.2 for citation is not properly broken in the middle. Editing will be helpful to fix it. We are looking forward to see the improvement after the WG LC, thank you. Best wishes, Haomian -邮件原件- 发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Adrian Farrel 发送时间: 2019年3月14日 6:01 收件人: pce@ietf.org 主题: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06 Hi working group, This email starts a working group last call for draft-ietf-pce-stateful-hpce-06. I would like to hear messages of support or concern about this draft. If you support its progression towards publication as an RFC, please let us know that you have read the latest revision, and explain why you think the work is important. Indications of implementation would also be welcome - although this document is informational, I believe some people may have built stateful hierarchical PCEs for experimentation or deployment. If you are opposed to the progression or have concerns please articulate them. As always, review comments and nits are most welcome. Because of the effort that is going in to preparing for IETF-104 and because of the time spent away, this last call will run for three weeks and end on April 4th. Thanks, Adrian ___ 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
Re: [Pce] I-D Action: draft-ietf-pce-stateful-hpce-09.txt
Hi All, A new version updating author email addresses and catching a couple of NITS. BR, Dan. -Original Message- From: I-D-Announce On Behalf Of internet-dra...@ietf.org Sent: 10 June 2019 12:39 To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-stateful-hpce-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Hierarchical Stateful Path Computation Element (PCE). Authors : Dhruv Dhody Young Lee Daniele Ceccarelli Jongyoon Shin Daniel King Oscar Gonzalez de Dios Filename: draft-ietf-pce-stateful-hpce-09.txt Pages : 22 Date: 2019-06-10 Abstract: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). The Path computation response from a PCE is helpful for the PCC to gracefully establish the computed LSP. The Hierarchical Path Computation Element (H-PCE) architecture, provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful, and not Stateless, PCEs using the Hierarchical PCE architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-hpce-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-hpce-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-ietf-pce-stateful-hpce-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Hierarchical Stateful Path Computation Element (PCE). Authors : Dhruv Dhody Young Lee Daniele Ceccarelli Jongyoon Shin Daniel King Oscar Gonzalez de Dios Filename: draft-ietf-pce-stateful-hpce-09.txt Pages : 22 Date: 2019-06-10 Abstract: A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). The Path computation response from a PCE is helpful for the PCC to gracefully establish the computed LSP. The Hierarchical Path Computation Element (H-PCE) architecture, provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful, and not Stateless, PCEs using the Hierarchical PCE architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-hpce-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-hpce-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
