[Pce] [PCE]:New Version Notification for draft-peng-pce-entropy-label-position-05.txt
Dear Dhruv,Stephane,Zhenbin Li,Tarek and WG, I just submitted a new version of the draft-peng-pce-entropy-label-position-05. This draft has been presented in IETF 106 and 107. Many thanks for your comments and discussions. First, I think we have the consensus that in case of inter-domain scenario, PCE would be useful for computing both SR path and the placement of entropy labels. We should propose a set of extensions for PCEP. Second, I fully agree with that the ingress MUST support the capability of inserting multiple ELI/ELs and it needs to advertise the capability to PCE. So I think we should add the capability in OPEN message from PCC to PCE. In the current version, we define the E bit for a PCC to indicate that it supports the capability of inserting multiple ELI/EL pairs and and supports the results of SR path with ELP from PCE. What is your suggestion? If the E bit is enough? Or should we define the BGP/IGP extension? Finally, thanks to Zhenbin, I need to clarify that the ELI/EL pairs are calculated for a specific traffic flow but the placement of the ELI/EL pairs are calculated for a SR-path. In our draft, we propose the PCEs perform computation of SR-path with the the placement of the ELI/EL pairs and the value of ELI/EL pairs are calculated at the ingress. I look forward and appreciate any comment and suggestion from you. Thanks, Quan 主 题 ：New Version Notification for draft-peng-pce-entropy-label-position-05.txt A new version of I-D, draft-peng-pce-entropy-label-position-05.txt has been successfully submitted by Quan Xiong and posted to the IETF repository. Name:draft-peng-pce-entropy-label-position Revision:05 Title:PCEP Extension for SR-MPLS Entropy Label Position Document date:2021-02-19 Group:Individual Submission Pages:9 URL: https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-05.txt Status: https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/ Htmlized: https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position Htmlized: https://tools.ietf.org/html/draft-peng-pce-entropy-label-position-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-peng-pce-entropy-label-position-05 Abstract: This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks. 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. The IETF Secretariat___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp
From: Pce on behalf of tom petch Sent: 19 February 2021 12:30 To: julien.meu...@orange.com Cc: pce@ietf.org Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp From: julien.meu...@orange.com Sent: 18 February 2021 10:35 Hi Tom, Thank you for your valuable feedback. The more I look, the less I like it. This I-D asks for an error code for missing mandatory TLV, a category which PCE has defined as Error-Type 6 and is referenced by such as pce-vn-association. Why does this I-D put missing mandatory TLV in a different Error-Type? I will raise some more issues next week. Tom Petch Some of the issues you point out are easy to address and we've already requested the authors to revise the I-D accordingly. To fully resolve your concern, could you please point any other specific parts where you feel you have to "interpret the words the way you think they should have been"? If you even have some text to suggest, that could smoothly ease the update. At a first glance, s.7.1 RFC8697 names three columns for the registry; those names do not appear here. The new association type is given a different identifier in different places. The preferred identifier needs to be nailed down since it is going into IANA forthwith and will be confusing to change thereafter. s.7.2 This requests new error values under Association Error and specifies a Type of 29. RFC8697 specifies a Type of 26 (29 is Path Computation Failure). 'Conflicting SRAG TLV' I find rather vague; conflicting with what? Likewise 'Multiple SRPAG from one LSP' s.7.3 This document defines five new TLVs That is TBD3, TBD4, TBD11, TBD5 and RFC8697 specifies the names of the fields in the registry, Those names are not used here. s.3.2 'as of the time of writing' will change its meaning as the I-D progresses; date needed s.4.1 'is only meant to be used' MUST NOT, SHOULD NOT, .? 'Policy Identifiers uniquely identify.. Policy Identifiers consist of Color.. Endpoint, optionally the policy hame. So if one is Color red, Endpoint NY no policy name and then one is requested for Color red, Endpoint NY, policy name standby that is a different triplet and so valid. Mmm. I can see that being mis-implemented s.4.2 'is meant to strictly correspond' MUST, SHOULD, ? s.5 This document specifies four new TLVs... These five TLVs . These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path identifiers, candidate path name and Candidate path preference.. That is five TLV. Wrong! That is four TLV and something completely different. When any of the mandatory TLVs Only one TLV is listed as mandatory SRPOLICY-CPATH-ID. s.5 At most only one .. can be carried and then goes on to describe the carriage of more than one; 'Only one ... SHOULD be present in a ... (whatever identifier you fix on) message. If more than one is present, only the first is processed and subsequent ones are silently discarded. A Normative Reference to an unadopted I-D that expires next week is not a good look:-) Like I said, the word that came to my mind was 'sloppy':-( Tom Petch Thanks, Dhruv & Julien On 17/02/2021 12:46, tom petch wrote: > > > I am sure that IANA will cope because they always do, but it will be by > reading between the lines, applying intelligence to what the authors may have > meant, and so on. Editorially this is a poor I-D (as yet), and that quality > verges on the technical aspects. > > Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs > in the body of the I-D. A reader might also notice the absence of TBD2 and > wonder. > > Or the new Association. Thus needs an identifier. Trouble is, the I-D uses > (at least) three different ones; this looseness of terminology can lead to > problems down the line. (MPLS I see as a classic in how not to specify IANA > registries and I see this heading the same way). > > Likewise the identifiers used in s.7 do not match those in current use, a > good way of storing up future trouble. > > Is the specification adequate? Only if you do not take it literally and > interpret the words the way you think they should have been. > > Tom Petch > ___ 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] [PCE]:New Version Notification for draft-peng-pce-entropy-label-position-05.txt
Hi, It is the job of ingress router to impose the SID(label) stack that would include one or more pairs of ELI/EL. This is always a subject to MSD limitations (per platform/per LC if applicable). The draft is not discussing implications of these limitations , which I find rather unfortunate. Regards, Jeff > On Feb 20, 2021, at 00:15, xiong.q...@zte.com.cn wrote: > > > Dear Dhruv,Stephane,Zhenbin Li,Tarek and WG, > > > > I just submitted a new version of the > draft-peng-pce-entropy-label-position-05. This draft has been presented in > IETF 106 and 107. Many thanks for your comments and discussions. > > > > First, I think we have the consensus that in case of inter-domain scenario, > PCE would be useful for computing both SR path and the placement of entropy > labels. We should propose a set of extensions for PCEP. > > > > Second, I fully agree with that the ingress MUST support the capability of > inserting multiple ELI/ELs and it needs to advertise the capability to PCE. > So I think we should add the capability in OPEN message from PCC to PCE. In > the current version, we define the E bit for a PCC to indicate that it > supports the capability of inserting multiple ELI/EL pairs and and supports > the results of SR path with ELP from PCE. What is your suggestion? If the E > bit is enough? Or should we define the BGP/IGP extension? > > > > Finally, thanks to Zhenbin, I need to clarify that the ELI/EL pairs are > calculated for a specific traffic flow but the placement of the ELI/EL pairs > are calculated for a SR-path. In our draft, we propose the PCEs perform > computation of SR-path with the the placement of the ELI/EL pairs and the > value of ELI/EL pairs are calculated at the ingress. > > > > I look forward and appreciate any comment and suggestion from you. > > > > Thanks, > > Quan > > > > > > 主 题 ：New Version Notification for draft-peng-pce-entropy-label-position-05.txt > > A new version of I-D, draft-peng-pce-entropy-label-position-05.txt > has been successfully submitted by Quan Xiong and posted to the > IETF repository. > > Name:draft-peng-pce-entropy-label-position > Revision:05 > Title:PCEP Extension for SR-MPLS Entropy Label Position > Document date:2021-02-19 > Group:Individual Submission > Pages:9 > URL: > https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-05.txt > Status: > https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position > Htmlized: > https://tools.ietf.org/html/draft-peng-pce-entropy-label-position-05 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-peng-pce-entropy-label-position-05 > > Abstract: >This document proposes a set of extensions for PCEP to configure the >entropy label position for SR-MPLS networks. > > > > > > 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. > > The IETF Secretariat > > > > ___ > 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
