[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04
Dear PCE WG I support progressing this draft to publication. This draft provides immense value to the operator community for deployment of RSVP-TE or segment routing with this new PCEP extension for a generic optional color TLV to carry color attribute part of tuple for SR policy by stateful PCE for color signaling overlay VPN color to underlay SR policy color, color to intent mapping binding candidate path (CP) ERO BSID to the forwarding plane. Kind Regards Gyan On Mon, Jun 3, 2024 at 11:51 PM Dhruv Dhody wrote: > Hi WG, > > This email starts a 2-weeks working group last call > for draft-ietf-pce-pcep-color-04. > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/ > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > The WG LC will end on Tuesday 18 June 2024. > > A general reminder to the WG to be more vocal during the > last-call/adoption. > > Thanks, > Dhruv & Julien > ___ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > ___ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
[Pce] Re: IPR poll for draft-ietf-pce-pcep-color
I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks Gyan On Tue, Jun 4, 2024 at 3:53 PM Andrew Stone (Nokia) wrote: > Hi Authors, > > > > In preparation for WGLC on this draft, we'd like all authors and > contributors to confirm on the list that they are in compliance with IETF > IPR rules. > > > > Please respond (copying the mailing list) to say one of: > > > > - I am not aware of any IPR applicable to this draft that should be > disclosed in accordance with IETF IPR rules. > > > > - I am aware of the IPR applicable to this draft, and it has already been > disclosed to the IETF. > > > > - I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > > > > > Thanks, > > Andrew > ___ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > ___ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04
Dear PCE WG As co-author I support publication. Thank you Gyan On Mon, Jun 3, 2024 at 11:51 PM Dhruv Dhody wrote: > Hi WG, > > This email starts a 2-weeks working group last call > for draft-ietf-pce-pcep-color-04. > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/ > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > The WG LC will end on Tuesday 18 June 2024. > > A general reminder to the WG to be more vocal during the > last-call/adoption. > > Thanks, > Dhruv & Julien > ___ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > ___ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16
Dear WG Sorry for the late reply. I support WG adoption of this draft and am willing to work on the draft. Few comments after reviewing the draft. For SR-MPLS there are two label rangers SRLB and SRGB. So you may want to have a label control space TLV with different IANA registry for sub TLV for SRLB and SRGB. Similarly for SRV6 Func ID control space TLV maybe have a separate IANA sub TLV for LIB (Local ID block) and GIB (Global ID block). IANA registry is not mentioned for BSID label or ID control space TLV. Also this ID space concept should be applicable to RSVP-TE as well. Also today a stateful PCE manages the LSP or SRv6 path PCE ERO via PCE delegation, however does not allocate a new label or sid range to be distributed to all nodes. However now this draft manages the service sid range. In a SR PCE environment where this new ID capability is advertised, is there any impact in distribution of this new ID space to all nodes in rebuilding the SR forwarding plane state. This should be added to the considerations section. Kind Regards Gyan On Fri, May 17, 2024 at 7:11 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-li-pce-controlled-id-space-16 > > https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/ > > 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. > > Please respond by Monday 3rd June 2024. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > ___ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls
Dear WG, I support WG adoption of this work. This work has had a long history and has matured and I believe is ready to be progressed. I believe that PCEP-LS would be valuable for operators and is not much change if using PCE CC centralized SDN controller. Thanks Gyan On Thu, Apr 4, 2024 at 12:18 PM wrote: > Hi all, > > We have a long history around PCEP-LS. The rough consensus has been to > progress it as experimental within the PCE WG, which makes more sense > than an independent submission. > As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become > a PCE WG document? Please share your feedback using the PCE mailing > list, including your comments and especially your rationales in case > you're opposed. > > Thank you, > > Julien > > --- > [1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > ___ > 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] IPR poll for draft-dhodylee-pce-pcep-ls
Hi Andrew I am not aware of any undisclosed IPRs. Thank you Gyan On Fri, Apr 5, 2024 at 5:14 PM Andrew Stone (Nokia) wrote: > Hi Authors, > > In preparation for WG adoption on this draft, we'd like all authors and > contributors to confirm on the list that they are in compliance with IETF > IPR rules. > > Please respond (copying the mailing list) to say one of: > > - I am not aware of any IPR applicable to this draft that should be > disclosed in accordance with IETF IPR rules. > > > > - I am aware of the IPR applicable to this draft, and it has already been > disclosed to the IETF. > > > > - I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > > > Thanks, > > Andrew > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10
Hi Quan
RFC 8662 talks about many interesting and creative ways to reduce the size
of the label stack.
Section 4 talks about ERLD and then 7.2.1 talks about ERLD value
computation.
I think it maybe good to mention what is discussed in both section 4 and
7.2.1.
Your draft does not use ERLD and uses ELP so I think explaining why ERLD
computation is not necessary specifically when using ELP flag.
Thanks
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Mon, Feb 5, 2024 at 10:53 PM wrote:
>
> Hi Gyan,
>
>
> Thanks for your comments! This is a good question.
>
>
> From my understanding, RFC8662 did not describe the ERLD computation is
> required but specifuies that the ingress " should try to insert the minimum
> number of such pairs".
>
> Also as suggested by Andrew, the explaination will be added in section 3
> as the following shown.
>
>
> "As described in [RFC8662], the ELRD value is an important consideration
> when inserting ELI/EL and the minimum ELRD must be evaluated for each node
> along a computed path. This necessary step adds additional complexity in
> the ELI/EL insertion process and it may not be feasible for an ingress
> router to compute the appropriate ERLD for each node in the path, since a
> SR-MPLS path may contain segments the ingress router can resolve such as
> inter-domain scenarios."
>
>
> It will be updated in the next version. Hope that could address your
> concern. Thanks!
>
>
> Best Regards,
>
> Quan
>
>
> Original
> *From: *GyanMishra
> *To: *Dhruv Dhody ;
> *Cc: *draft-peng-pce-entropy-label-posit...@ietf.org <
> draft-peng-pce-entropy-label-posit...@ietf.org>;pce@ietf.org
> ;pce-chairs
> ;
> *Date: *2024年02月06日 11:12
> *Subject: **Re: [Pce] WG Adoption of
> draft-peng-pce-entropy-label-position-10*
>
> I reviewed the draft and support WG adoption.
>
> I believe this ELP PCE capability extension maybe helpful in determining
> the position to place the ELI. EL label. According to RFC 8662 a {ELI,EL}
> label must be placed after every SID in the sid list based on the ERLD. I
> maybe a good idea to explain why computing the ERLD would add complexity in
> the ELI/EL insertion process and why a new mechanism using the ELP is
> necessary. Also why the ERLD computation is not required as described in
> RFC 8662.
>
> Thanks
>
> Gyan
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
>
> On Fri, Jan 26, 2024 at 11:50 AM Dhruv Dhody wrote:
>
>> Hi WG,
>>
>> This email begins the WG adoption poll for
>> draft-peng-pce-entropy-label-position-10
>>
>> https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/
>>
>> 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.
>>
>> Please respond by Monday 12th Feb 2024.
>>
>> Please be more vocal during WG polls!
>>
>> 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
Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10
I reviewed the draft and support WG adoption.
I believe this ELP PCE capability extension maybe helpful in determining
the position to place the ELI. EL label. According to RFC 8662 a {ELI,EL}
label must be placed after every SID in the sid list based on the ERLD. I
maybe a good idea to explain why computing the ERLD would add complexity in
the ELI/EL insertion process and why a new mechanism using the ELP is
necessary. Also why the ERLD computation is not required as described in
RFC 8662.
Thanks
Gyan
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Fri, Jan 26, 2024 at 11:50 AM Dhruv Dhody wrote:
> Hi WG,
>
> This email begins the WG adoption poll for
> draft-peng-pce-entropy-label-position-10
>
> https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/
>
> 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.
>
> Please respond by Monday 12th Feb 2024.
>
> Please be more vocal during WG polls!
>
> 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
Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12
I support publication. I have reviewed v12 and have a few minor comments. At the end of the abstract section you could say forwarding planes of SR instead of dataplane. As the data planes of SR would be MPLS and IPv6. Old The mechanism is applicable to all data planes of SR (MPLS, SRv6, etc.). New The mechanism is applicable to SR forwarding planes of SR (SR-MPLS SRv6, etc.). My understanding is that as RFC 8664 is the base PCEP extension for SR and this draft is an add on to the base SR PCEP extension to provide the CP support. My thoughts was a more appropriate name for the draft as "PCEP extension for SR Policy Candidate paths" or "PCEP SR Extension for Candidate paths" Kind Regards <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* On Mon, Jan 8, 2024 at 5:29 AM Dhruv Dhody wrote: > Hi WG, > > This email starts a 2-weeks working group last call for > draft-ietf-pce-segment-routing-policy-cp-12. > > https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ > > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > The WG LC will end on Monday 22nd January 2024. > > A general reminder to the WG to be more vocal during the > last-call/adoption. > > 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
Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
I support the adoption of pcep extension to support circuit style sr policy. I don’t see any issues with the draft that need to be fixed and I am willing to work on the draft. Thanks <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* On Fri, Dec 1, 2023 at 5:33 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-sidor-pce-circuit-style-pcep-extensions-05. > > > https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ > > 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. > > Please respond by Friday 15th Dec 2023. > > Please be more vocal during WG polls! > > 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
Re: [Pce] WG Adoption of draft-chen-pce-bier-11
I support WG adoption. Thanks Gyan On Mon, Sep 25, 2023 at 12:50 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-chen-pce-bier-11. > > https://datatracker.ietf.org/doc/draft-chen-pce-bier/ > > 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. > > Please respond by Monday 9th Oct 2023. > > Please be more vocal during WG polls! > > 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
Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor
I support adoption. Thanks Gyan On Tue, Jun 20, 2023 at 3:46 AM wrote: > Hi all, > > It has been a while since draft-dhody-pce-stateful-pce-vendor started to > document how to extend the scope of RFC 7470. It is now time to consider > its adoption by the WG. > Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to > become a PCE work item? Please express your support and/or concerns > using the mailing list. > > Thanks, > > Dhruv & Julien > > > [1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
I have read the draft and support publication of the PCE SRv6 extension. I don’t see anything SRv6 compression related which uses the same endpoint behavior semantics from RFC 8986 SRv6 PGM but with new endpoint flavors for C-SID Next SID (Cisco uSID) and Replace SID (Huawei GSID). Also the related caveat that with SRv6 uSID as compare GSID the SRH is not present for less than 5 uSID hops loose or strict steering which can be accomplished with underlay ISIS SR Algo advertisement as L2 EVPN and L3 VPN service label is encoded into the FUNC field so so does not require PCE or SR policy to instantiate. With SRv6 uSID stateful PCE and SR policy would come into play for greater than 5 uSID uN shift-forward hops of steering. https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ Thanks Gyan On Mon, Feb 13, 2023 at 12:38 PM wrote: > Dear PCE WG, > > This message starts a 2-week WG last call on > draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any > comments you have about this document using the PCE mailing list. > > This WGLC will end on Tuesday 28th February 2023. > > Thanks, > > Julien > > -- > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6
I support WG adoption of PCEP PCECC centralized controller extension for SRv6. Thanks Gyan On Mon, Jan 16, 2023 at 1:00 PM wrote: > Hi all, > > This e-mail starts an adoption poll for > draft-dhody-pce-pcep-extension-pce-controller-srv6-10 [1]. Do you > consider this I-D is ready to become a PCE WG item? > > Please respond to the PCE list, including rationale if you believe the > WG should not adopt it. > > Thanks, > > Julien > > > [1] > > https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/ > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Rtgdir early review of draft-ietf-pce-pcep-yang-20
Reviewer: Gyan Mishra Review result: Not Ready This draft provides the Yang model for PCEP. The Yang model should include all PCEP related extensions and which from reading the draft I see missing some major components that should be included detailed in this review. Minor issues: Normative and / or Informative References to the following drafts should be included as well as I see are missing in the PCEP Yang model itself: H-PCE https://datatracker.ietf.org/doc/html/rfc8751 SR related content missing from Yang model PCEP Centralized Controller https://datatracker.ietf.org/doc/html/rfc9050 SR PCE Extension https://datatracker.ietf.org/doc/html/rfc8664 SR EPE https://datatracker.ietf.org/doc/html/rfc9086 SR EXT https://datatracker.ietf.org/doc/html/rfc9085 SRv6 PCE extension https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ SRv6 PGM https://datatracker.ietf.org/doc/html/rfc8986 SRv6 SRH https://datatracker.ietf.org/doc/html/rfc8754 SRv6 Compression https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02 Transport Network Modernization related GMPLS / MPLS-TP PCEP extension for GMPLS https://www.rfc-editor.org/rfc/rfc8282.html https://datatracker.ietf.org/doc/rfc8779/ RSVP TE extension for Co routed LSP ( Enhanced RSVP-TE) Allows operators to use converged network to support both unidirectional LSP and co-routed on same MPLS data plane without changing the MPLS data plane as is with MPLS-TP. https://www.rfc-editor.org/rfc/rfc7551.html https://datatracker.ietf.org/doc/html/rfc9059 MPLS-TP Co routed path https://datatracker.ietf.org/doc/html/rfc6373 PCEP stateful coloring extension https://datatracker.ietf.org/doc/html/draft-rajagopalan-pce-pcep-color ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-rajagopalan-pce-pcep-color-02
I support WG adoption by the PCE WG. SR Policy VPN service route color to intent mapping is an important aspect of Segment Routing to instantiate per flow or per destination steering and this draft provides a PCEP extension to carry the coloring inter domain. This is a very useful and important draft for operators migrating to segment routing. Thank you Gyan On Thu, Dec 1, 2022 at 12:07 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-rajagopalan-pce-pcep-color-02. > > https://datatracker.ietf.org/doc/draft-rajagopalan-pce-pcep-color/ > > 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. > > Please respond by Friday 16th Dec 2022. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-rajagopalan-pce-pcep-color-02
I am not aware of any undisclosed IPR. Thanks Gyan On Thu, Dec 1, 2022 at 4:24 PM Hariharan Ananthakrishnan wrote: > Hi Authors, > > In preparation for WG adoption on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of the IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-li-pce-pcep-srv6-yang-07
This draft is very useful for operators deploying SRv6 and I support adoption. Should the Yang model include all SRv6 endpoint behaviors defined in RFC 8986 SRv6 programming? Also should the draft include RFC 9252 SRv6 BGP overlay service and transposition scheme details as well as SRv6 load balancing? As well should the draft include SRv6 compression Next uSID and Replace G-SID endpoint behaviors? Thanks Gyan On Fri, Sep 2, 2022 at 5:10 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-li-pce-pcep-srv6-yang-07. > > https://datatracker.ietf.org/doc/draft-li-pce-pcep-srv6-yang/ > > 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. > > Please respond by Monday 19th Sept 2022. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Dear WG I support adoption by PCE WG and would be willing to work on the draft. I support IFIT PCE extension to carry the IFIT attributes for in-situ IOAM on path telemetry. I do agree this would be very useful for operators. I was looking for a framework draft for IFIT and this is what I found. I think a framework draft for IFIT solution should be addressed in the draft in the introduction. I noticed that there are a number of ifit related drafts across many WGs with a variety of authors and it appears no common author across all the documents. Is there an IFIT framework draft of the overall IFIT architecture and goals? IFIT is a component of IPPM IOAM but I think it should have its own framework draft. I did find this IFIT framework draft which I don’t see as informational reference in this document. https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ Of all the IFIT related drafts I do see one adopted. https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-ifit/ Kind Regards Gyan On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06. > > https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/ > > 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. > > Please respond by Monday 11th July 2022. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-flags-02
supported by the implementation, it will consider the > bits >> beyond the length to be unset. >> … ….” >> >> Will the above lead > to misbehavior in some situations? >> >> > A (TLV L=8) -- B (TLV L=4) > > When A receives an LSP-EXTENDED-FLAG TLV with Length = 4, even though it > > understands/supports more flags than 32, it considers that those other > > flags are unset for B. > When B receives an LSP-EXTENDED-FLAG TLV with > Length = 8, since B only > understands limited bits, it considers all the > other ones as unassigned and > ignores them. > > Note that this behavior is > similar to how considering A supports 10 flags > and B supports 3 flags > would be handled even though the L > =4 for both. > > What am I missing? > > Anyway, I rec! > ommend the fixed length(then the length field is unnecessary) >> and > clear description/usages of each bit of the flag. >> >> > This document > creates the TLV and a registry. The actual bits and their > usage belong in > other documents. > > Thanks! > Dhruv (as a WG member) > > > >> Aijun Wang > >> China Telecom >> >> On May 11, 2022, at 21:28, Dhruv Dhody ">< > d...@dhruvdhody.com> wrote: >> >> >> Hi WG, >> >> This email starts a > 2-weeks working group last call for >> draft-ietf-pce-lsp-extended-flags-02 > [1]. >> >> Please indicate your support or concern for this draft. If you > are >> opposed to the progression of the draft to RFC, please articulate > your >> concern. If you support it, please indicate that you have read the > latest >> version and it is ready for publication in your opinion. As > always, review >> comments and nits are most welcome. >> >> The WG LC will > end on Wednesday 25th May 2022. >> >> A general reminder to the WG to be > more vocal during the >> last-call/adoption and help u > s unclog our queues :) >> >> Thanks, >> Dhruv & Julien >> >> [1] > https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/>> > ___ >> Pce mailing list >> > Pce@ietf.org>> https://www.ietf.org/mailman/listinfo/pce>> >> > [Pce] WGLC for draft-ietf-pce-lsp-extended-flags-… Dhruv Dhody > Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Aijun Wang > Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Dhruv Dhody > Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Aijun Wang > Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Dhruv Dhody > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Dear PCE Chairs After the discussion thread with Ketan we are now in sync and I have agreed to work with the authors of the IDR and PCE draft in a collaborative effort on publishing a draft in SPRING WG that addresses PMTU in SR Policy and Fragmentation in SR policy. I have discussed with the PCE authors that I agree that PMTU in SR Policy definition and SR Policy and fragmentation should be in a Spring Standards Track draft from an implementation standpoint to avoid any interoperability issues in proprietary vendor specific definitions of PMTU in SR Policy. Anything SR architecture related which PMTU and fragmentation in SR policy are part of the SR architecture which is why it belongs in Spring. We have reached an agreement that the PCE draft can proceed for Adoption and once it becomes a WG document we will ensure that protocol specific encoding is only included in the PCE draft with informational reference to the new Spring PMTU draft that has the detailed framework of PMTU in SR Policy specification. Ketan has offered to help in editing the new draft. As well if anyone else in Spring or PCE would like to collaborate on the draft please let us know. Kind Regards Gyan On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05. > > https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/ > > 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. > > Please respond by Monday 11th April 2022. > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi Ketan Please see in-line below Gyan2. On Thu, Apr 21, 2022 at 10:32 AM Ketan Talaulikar wrote: > Hi Gyan, > > Please check inline below with KT2. > > > On Thu, Apr 21, 2022 at 1:07 AM Gyan Mishra wrote: > >> Hi Ketan >> >> Please see in-line >> >> Thanks >> >> On Wed, Apr 20, 2022 at 7:10 AM Ketan Talaulikar >> wrote: >> >>> Hi Gyan, >>> >>> Please check inline below. >>> >>> >>> On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra >>> wrote: >>> >>>> >>>> Hi Ketan >>>> >>>> >>>> On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I do not believe this document is ready for adoption. I believe the WG >>>>> perhaps needs to discuss some basic concepts before taking up this work. >>>>> >>>>> Please note that I do not object to (what I infer is) the motivation >>>>> for this work. This document is not (yet) a good starting point for this >>>>> work. >>>>> >>>>> 1) We need a SPRING WG document that covers the considerations related >>>>> to Path MTU for SR Policies. We do not have such a document today. While >>>>> this document does touch upon certain aspects, it is inadequate. This >>>>> document should focus more on the PCEP protocol aspects and rely on the >>>>> existing RSVP-TE spec RFC3209 and TBD for SR Policy for the application to >>>>> the respective constructs. Note that draft-ietf-idr-sr-policy-path-mtu >>>>> introduces this PMTU for BGP SRTE [*] >>>>> >>>> >>>> Gyan> As Spring SR Policy draft has already been submitted for >>>> publication, could we add verbiage to the IDR SR Policy draft and as this >>>> draft is BGP SR policy related PCE extension for PMTUD similar to the IDR >>>> SR policy PMTU draft mentioned. >>>> >>> >>> KT> I do not see these mechanisms as being protocol specific and hence >>> do not seem right for either PCEP or BGP documents. >>> >> >> Gyan> Understood. So PMTU related protocol specific in the IDR and >> PCEP documents and PMTU in SR policy specifics in a Spring Informational >> document? >> > > KT2> Yes. > > >> >>> >>>> I read the comments from the IDR adoption call as it relates to SR and >>>> PMTU. I think we all agree that the goal of this and the IDR drafts are >>>> warranted. However as PMTUD even as it relates to SR is not overly >>>> complicated that we need a draft to explain what constitutes the total SR >>>> packet size, as SR is not any different from any other technology from a >>>> packet sizing perspective. The same concept that the lowest MTU link >>>> along a path is the maximum MTU PMTU for the path is valid and that is the >>>> basis for PMTU. I don’t think this should hold up the adoption call. >>>> >>> >>> KT> We've had this conversation in the IDR WG during the IDR document >>> adoption and we don't yet have a SPRING document. I am not sure if the PCEP >>> work proceeds in a similar manner. I will leave it to the WG chairs' >>> judgment on this matter. >>> >> >> Gyan> I reviewed the mail archive on the discussion and your request >> for a PMTU in SR policy Spring document. I think this is an important >> issue to be solved related to PMTU to prevent fragmentation for operators. >> > > KT2> We have SR-MPLS and SRv6. For each of them, we have different kinds > of payload - IPv4, IPv6, MPLS, Ethernet, etc. which have different > characteristics when it comes to whether or not fragmentation can be > performed at the SR Policy head-end. > Gyan2> Understood. So a design document that goes into the details related to fragmentation on SR Policy head end SID list candidate path instantiated and the impact of fragmentation on intermediate nodes. The goal of the IDR and PCE drafts is in solution space to prevent fragmentation from happening using PMTU. Fragmentation aspect of SR Policy instantiation is the problem and I agree that should be in Spring WG and I would be happy to collaborate on that draft. I agree that SR Policy PMTU should also be part of that Spring draft. > > >> Would this draft go into the details of how fragmentation would work with >> SR problem statement or would it just
Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi Ketan Please see in-line Thanks On Wed, Apr 20, 2022 at 7:10 AM Ketan Talaulikar wrote: > Hi Gyan, > > Please check inline below. > > > On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra > wrote: > >> >> Hi Ketan >> >> >> On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar >> wrote: >> >>> Hello, >>> >>> I do not believe this document is ready for adoption. I believe the WG >>> perhaps needs to discuss some basic concepts before taking up this work. >>> >>> Please note that I do not object to (what I infer is) the motivation for >>> this work. This document is not (yet) a good starting point for this work. >>> >>> 1) We need a SPRING WG document that covers the considerations related >>> to Path MTU for SR Policies. We do not have such a document today. While >>> this document does touch upon certain aspects, it is inadequate. This >>> document should focus more on the PCEP protocol aspects and rely on the >>> existing RSVP-TE spec RFC3209 and TBD for SR Policy for the application to >>> the respective constructs. Note that draft-ietf-idr-sr-policy-path-mtu >>> introduces this PMTU for BGP SRTE [*] >>> >> >> Gyan> As Spring SR Policy draft has already been submitted for >> publication, could we add verbiage to the IDR SR Policy draft and as this >> draft is BGP SR policy related PCE extension for PMTUD similar to the IDR >> SR policy PMTU draft mentioned. >> > > KT> I do not see these mechanisms as being protocol specific and hence do > not seem right for either PCEP or BGP documents. > Gyan> Understood. So PMTU related protocol specific in the IDR and PCEP documents and PMTU in SR policy specifics in a Spring Informational document? > > >> I read the comments from the IDR adoption call as it relates to SR and >> PMTU. I think we all agree that the goal of this and the IDR drafts are >> warranted. However as PMTUD even as it relates to SR is not overly >> complicated that we need a draft to explain what constitutes the total SR >> packet size, as SR is not any different from any other technology from a >> packet sizing perspective. The same concept that the lowest MTU link >> along a path is the maximum MTU PMTU for the path is valid and that is the >> basis for PMTU. I don’t think this should hold up the adoption call. >> > > KT> We've had this conversation in the IDR WG during the IDR document > adoption and we don't yet have a SPRING document. I am not sure if the PCEP > work proceeds in a similar manner. I will leave it to the WG chairs' > judgment on this matter. > Gyan> I reviewed the mail archive on the discussion and your request for a PMTU in SR policy Spring document. I think this is an important issue to be solved related to PMTU to prevent fragmentation for operators. Would this draft go into the details of how fragmentation would work with SR problem statement or would it just detail the PMTU protocol specific BGP and PCEP solution? If the authors of the PCEP draft published an informational draft on PMTU in SR Policy as it relates to both IDR and PCE drafts would that suffice? > > Thanks, > Ketan > > >> >>> 2) There seems to be some degree of mixup between the concept of (a) >>> constraint for the path and (b) the reporting of the calculated path MTU of >>> the path. Both are perhaps needed, but we need them to be unambiguous and >>> differentiated. I would think that (a) is also very useful. And I am not >>> sure if it is appropriate to refer to (b) as a "metric" - isn't it a >>> property? >>> >> >> >> >>> >>> 3) This is applicable for both RSVP-TE and SR Policy. >>> >> >> Gyan> Agreed >> >>> >>> [*] What I see is that some amount of uncoordinated protocol spec >>> development related to SPRING constructs is happening in the >>> protocol-specific WGs (PCE & IDR) without the base work being done in the >>> SPRING WG. I had raised this point during the IDR document adoption as >>> well: >>> https://mailarchive.ietf.org/arch/msg/idr/ZrN1-Uw1ggyxKeltBICmcthjymM/ >>> >>> Thanks, >>> Ketan >>> >>> >>> >>> On Mon, Mar 28, 2022 at 9:40 PM Dhruv Dhody wrote: >>> >>>> Hi WG, >>>> >>>> This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05. >>>> >>>> https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/ >>>> >>>> Should this
Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi Dhruv I reviewed the draft and support WG adoption. Should this draft be adopted by the PCE WG? Yes Please state your reasons - Why / Why not? This documents PCEP PMTU extension is valuable for any operator deployments of SR-MPLS or SRv6 and/or uses SR-TE and want to ensure that fragmentation does not occur along the stateful path instantiated. What needs to be fixed before or after adoption? The document well written and to the point and is ready for adoption Are you willing to work on this draft? Yes I would be happy to collaborate on the draft Review comments should be posted to the list. Few comments for the authors below: It maybe worthwhile to mention PMTUD path MTU discovery which allows a TCP session to dynamically adjust the MSS for incoming and outgoing MSS. As this document utilizes PMTU which is based on the PMTUD concept which is being carried in a new metric field in the PCEP report message I think for clarity it would. BGP uses TCP and by default most all vendor implementations have PMTUD enabled by default on all BGP sessions. Maybe worthwhile mentioning. In the abstract I don’t understand this sentence. Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. I understand SR eliminates the control plane signaling for label distribution LDP which is now via IGP extension, but how does that make it so the SR MTU information is not available. Directed LDP is for adjacency nodes or targeted LDP for session protection for non directly connected nodes. RFC 5036 LDP does not support signaling for MTU. RFC 7552 LDP updates for IPv6 also does not support signaling for MTU. RFC 3988 is an experimental extension to support signaling for MTU. I see RFC 3988 as a informational reference. I think it would be good to mention what I stated above related to LDP not providing any signaling for MTU and RFC 3988 as its experimental and not standard track also not implemented by all vendors. Section 3.5 mentions that path MTU adjustment can be made for primary or TI-LFA local protection path. I would think this can be used for SR-TE protected path instantiated by stateful PCE but not for local protection. Also would this draft be applicable to Non SR MPLS and GMPLS LDP signaling RFC 3988 is experimental only so MPLS and GMPLS as well have a gap for MTU signaling. I do see you stated in the introduction. You may want to state the gap that exists as RFC 3988 is experimental and now this solution fills that gap as well. Thanks Gyan On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05. > > https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/ > > 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. > > Please respond by Monday 11th April 2022. > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05
I support WG adoption of this important PCEP FlexAlgo extension and I am willing to work on the draft to progress. Thanks Gyan On Fri, Feb 4, 2022 at 12:15 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05. > > https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/ > > 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. > > Please respond by Monday 21st Feb 2022. > > Have a great weekend. > > Thanks! > Dhruv & Julien > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-vn-association-05
Hi Dhruv Makes sense. Thanks Gyan On Thu, Mar 17, 2022 at 1:20 AM Dhruv Dhody wrote: > Hi Gyan, > >> >> Dear Authors, >> >> Does this draft update RFC 8697 or any other PCEP RFC? >> >> > As the author of RFC 8697, I don't think a PCEP extension defining a new > association type needs to update RFC 8697. The idea of RFC 8697 was to > define just the object and let future extensions define association types > as done by RFC 8745, 8800, 9005, 9059 (none of them update RFC 8697). > > Thanks! > Dhruv > > > > >> Thanks >> >> Gyan >> >> On Wed, Mar 16, 2022 at 2:10 AM Ricard Vilalta >> wrote: >> >>> Hi WG, >>> >>> >>> >>> I have read the draft and I support the publication of this draft. >>> >>> >>> >>> Thanks, >>> >>> Ricard >>> >>> >>> >>> >>> >>> -- >>> >>> Ricard Vilalta >>> >>> Senior Researcher >>> >>> ricard.vila...@cttc.es >>> >>> >>> >>> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) >>> >>> Av. Carl Friedrich Gauss, 7 - Building B4 >>> <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail=g> >>> >>> 08860 - Castelldefels >>> <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail=g> >>> >>> Tel.: +34 93 645 29 00 >>> >>> >>> >>> DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE >>> TELECOMUNICACIONS DE CATALUNYA (G62616586): >>> >>> >>> >>> We inform you that your identification data and the data contained in >>> the emails and attached files can be incorporated into our databases, in >>> order to maintain professional and / or commercial relationships, and that >>> it will be preserved throughout the relationship. According to the current >>> regulations, you can exercise your right to access, rectification, erasure, >>> restriction of processing, to portability and to object by sending an email >>> to d...@cttc.cat. >>> >>> This message and any attached document, where appropriate, may be >>> confidential and intended for the original recipient only. >>> >>> >>> >>> Before printing this e-mail or attachments, be sure it is necessary. It >>> is in our hands to protect the environment. >>> >>> >>> >>> *De:* Pce *En nom de *Aihua Guo >>> *Enviat:* miércoles, 16 de marzo de 2022 4:02 >>> *Per a:* Dhruv Dhody >>> *A/c:* draft-ietf-pce-vn-associat...@ietf.org; pce@ietf.org; pce-chairs >>> >>> *Tema:* Re: [Pce] WGLC for draft-ietf-pce-vn-association-05 >>> >>> >>> >>> Hi WG, >>> >>> >>> >>> I have read the draft and I support the publication of this draft. >>> >>> >>> >>> Thanks, >>> >>> Aihua >>> >>> >>> >>> >>> >>> On Tue, Feb 22, 2022 at 7:19 AM Dhruv Dhody wrote: >>> >>> Hi WG, >>> >>> This email starts a 3-weeks working group last call for >>> draft-ietf-pce-vn-association-05 [1 >>> <https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/>] to >>> accommodate the upcoming draft submission deadline. >>> >>> Please indicate your support or concern for this draft. If you are >>> opposed to the progression of the draft to RFC, please articulate your >>> concern. If you support it, please indicate that you have read the latest >>> version and it is ready for publication in your opinion. As always, review >>> comments and nits are most welcome. >>> >>> The WG LC will end on Tuesday 15th March 2022. >>> >>> A general reminder to the WG to be more vocal during the >>> last-call/adoption and help us unclog our queues :) >>> >>> Thanks, >>> Dhruv & Julien >>> >>> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/ >>> >>> ___ >>> 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 >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mis...@verizon.com * >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-vn-association-05
Dear WG I read the draft and support publication. This document specifies a PCEP extension to associate a set of LSPs to a newly defined VN association Group (VNAG). Dear Authors, Does this draft update RFC 8697 or any other PCEP RFC? Thanks Gyan On Wed, Mar 16, 2022 at 2:10 AM Ricard Vilalta wrote: > Hi WG, > > > > I have read the draft and I support the publication of this draft. > > > > Thanks, > > Ricard > > > > > > -- > > Ricard Vilalta > > Senior Researcher > > ricard.vila...@cttc.es > > > > Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) > > Av. Carl Friedrich Gauss, 7 - Building B4 > <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail=g> > > 08860 - Castelldefels > <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail=g> > > Tel.: +34 93 645 29 00 > > > > DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE > TELECOMUNICACIONS DE CATALUNYA (G62616586): > > > > We inform you that your identification data and the data contained in the > emails and attached files can be incorporated into our databases, in order > to maintain professional and / or commercial relationships, and that it > will be preserved throughout the relationship. According to the current > regulations, you can exercise your right to access, rectification, erasure, > restriction of processing, to portability and to object by sending an email > to d...@cttc.cat. > > This message and any attached document, where appropriate, may be > confidential and intended for the original recipient only. > > > > Before printing this e-mail or attachments, be sure it is necessary. It > is in our hands to protect the environment. > > > > *De:* Pce *En nom de *Aihua Guo > *Enviat:* miércoles, 16 de marzo de 2022 4:02 > *Per a:* Dhruv Dhody > *A/c:* draft-ietf-pce-vn-associat...@ietf.org; pce@ietf.org; pce-chairs < > pce-cha...@ietf.org> > *Tema:* Re: [Pce] WGLC for draft-ietf-pce-vn-association-05 > > > > Hi WG, > > > > I have read the draft and I support the publication of this draft. > > > > Thanks, > > Aihua > > > > > > On Tue, Feb 22, 2022 at 7:19 AM Dhruv Dhody wrote: > > Hi WG, > > This email starts a 3-weeks working group last call for > draft-ietf-pce-vn-association-05 [1 > <https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/>] to > accommodate the upcoming draft submission deadline. > > Please indicate your support or concern for this draft. If you are opposed > to the progression of the draft to RFC, please articulate your concern. If > you support it, please indicate that you have read the latest version and > it is ready for publication in your opinion. As always, review comments and > nits are most welcome. > > The WG LC will end on Tuesday 15th March 2022. > > A general reminder to the WG to be more vocal during the > last-call/adoption and help us unclog our queues :) > > Thanks, > Dhruv & Julien > > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/ > > ___ > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
t; > - Use a figure to specifically imply values for TBD1 and TBD2 > > > > I suggest that you: > > - remove the figure > > - mention TBD1 and TBD2 in the text > > > > --- > > > > 7.2.2 > > > > Will you ask IANA to maintain a registry for the Flags field? > > > > --- > > > > 7.2.2 > > > > You have > > > >This sub-object is OPTIONAL in the exclude route object (XRO) and > >can be present multiple times. When a stateful PCE receives a PCReq > >message carrying this sub-object, it SHOULD search for the > >identified LSP in its LSP-DB and then exclude from the new path > >computation all resources used by the identified LSP. > > > > Your use of "SHOULD" here implies that an implementation has a choice to > > do something different. You need to say: > > - what different thing MAY a PCE do? > > - why might it make that choice? > > > > (Or make this "MUST") > > > > --- > > > > 7.2.3 refers to TBD6, but 10.3 has TBD4 > > > > --- > > > > In 8.1 and 8.2 you have that the PCE SHOULD do things without specifying > > what else it might do and why. You also have some cases of lower case > > "should" which don't seem right. > > > > --- > > > > 8.3 has > > > >If the PCC does not support the END-POINTS Object of type > >Generalized Endpoint, the PCC MUST send a PCErr message with Error- > >type = 3(Unknown Object), Error-value = 2(unknown object type). > > > > I think this is not new behaviour so you need to point to the spec that > > defines this with "...per [RFC5440]..." > > > > > > == Nits == > > > > Throughout > > > > Please be careful with "sub-object" and "subobject" > > > > --- > > > > 1. > > > > s/and does not cover the GMPLS/and do not cover GMPLS/ > > > > --- > > > > 1. Final paragraph > > > > Introduce a new paragraph break before "This document focuses..." > > > > --- > > > > 1. > > > > s/Protocol extensions is included/Protocol extensions are included/ > > > > --- > > > > 3. > > > > s/PCE, PCUpd message/PCE, a PCUpd message/ > > s/delegated to PCE/delegated to the PCE/ > > s/by the PCC to PCE/from the PCC to the PCE/ > > > > --- > > > > 3. > > > > Furthermore, the Initiation of PCEP are > > > > Is that... > > Furthermore, the Initiation of PCEP sessions are > > ...or... > > Furthermore, the Initiation phase of PCEP is > > ...or... > > Furthermore, the PCInitiate PCEP message is > > ...or... > > Furthermore, the LSP Initiation function of PCEP is > > > > --- > > > > 3. > > > > s/to initiate the LSP establishment/to initiate LSP establishment/ > > > > --- > > > > 3. > > > > OLD > >Some of these Objects/TLVs > >may require modifications to incorporate stateful PCE where > >applicable > > NEW > >Where these Objects/TLVs > >require modifications to incorporate stateful PCE, they are > >described in this document. > > END > > > > --- > > > > 4. > > > > s/were covered in [RFC8231]/are covered in [RFC8231]/ > > s/provides extension for/provides extensions for/ > > s/capable to indicate/capable of indicating/ > > s/capabilities per TE/capabilities a per TE/ > > > > --- > > > > 4. > > > > OLD > > Such information would be needed for > > PCEP message. > > NEW > > Such information would need to be included > > in various PCEP messages. > > END > > > > --- > > > > 4. > > > > s/some technologies path/some technologies, path/ > > s/Stateful PCEP message also/Stateful PCEP messages also/ > > > > --- > > > > 5. Overview of PCEP Extensions for GMPLS Networks > > > > I think this might be > > > > 5. Overview of Stateful PCEP Extensions for GMPLS Networks > > > > --- > > > > 5.1 > > > > s/introduced as flag/introduced as flags/ > > > > --- > > > > 5.2 > > > > s/attributes include bandwidth/attributes including bandwidth/ > > s/modified LSP during/modified LSPs during/ > > > > --- > > > > 5.4 > > > > s/stateful PCE mechanism/
Re: [Pce] Call for slot in the PCE WG at IETF 112
Dear Chairs I would like to request a 10 minute time slot to present this draft at IETF 112 and ask to poll for support and adoption call. https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ Kind Regards Gyan On Tue, Oct 12, 2021 at 10:30 AM Dhruv Dhody wrote: > Hi, > > The PCE WG would be meeting during the IETF 112 [1 > <https://datatracker.ietf.org/meeting/112/agenda>] week. If you need > agenda time to progress some work, please send a slot request directly to > the chairs/secretary by Monday, Oct 25th by > including: > > - the draft(s) you want to discuss, > - the expected presenter name, > - the requested duration, including question time as part of the slot, > - the reason why you want to be on the agenda; What do you want to > achieve? Why is a presentation necessary to achieve it? > > Please note - Asking for a slot does not mean you will get one. We will be > prioritizing moving WG work first as well as drafts that were discussed on > the mailing list. Please make sure to introduce your new draft or summarize > an update on the mailing list. The last date to submit drafts is also > Monday, Oct 25th [2 > <https://datatracker.ietf.org/meeting/important-dates/>]. > > Thanks! > PCE Chairs & Secretary > > [1] https://datatracker.ietf.org/meeting/112/agenda > [2] https://datatracker.ietf.org/meeting/important-dates/ > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional
I support WG adoption. Thanks Gyan On Tue, Sep 21, 2021 at 3:14 PM Bidgoli, Hooman (Nokia - CA/Ottawa) < hooman.bidg...@nokia.com> wrote: > Support > > Thanks > Hooman > > -Original Message- > From: Pce On Behalf Of julien.meu...@orange.com > Sent: Tuesday, September 21, 2021 10:01 AM > To: pce@ietf.org > Subject: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional > > Hi all, > > This e-mail starts an adoption poll for > draft-dhody-pce-stateful-pce-optional-08 [1]. Do you consider this I-D is > ready to become a PCE WG item? > > Please respond to the PCE list, including rationale if you believe the WG > should not adopt it. > > Thanks, > > Dhruv & Julien > > > [1] > > https://datatracker.ietf.org/doc/html/draft-dhody-pce-stateful-pce-optional-08 > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
Perfect! Thanks Gyan On Fri, Aug 27, 2021 at 8:01 AM Adrian Farrel wrote: > -22 captures it. Thanks, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 27 August 2021 06:52 > *To:* adr...@olddog.co.uk > *Cc:* Dhruv Dhody ; draft-dhodylee-pce-pcep...@ietf.org; > pce@ietf.org; pce-chairs > *Subject:* Re: draft-dhodylee-pce-pcep-ls next steps! > > > > > > Hi Adrian > > > > Agreed. We will make it more clear. > > > > Many Thanks! > > > > Gyan > > > > On Wed, Aug 25, 2021 at 10:30 AM Adrian Farrel > wrote: > > Yes, thanks, Gyan. > > > > I think you have captured it all, although some of the behaviours are > “hidden” in assumptions in the text. > > > > That is: > > > >- A PCEP speaker that offers this feature to its peer that does not >support or does not wish to support the feature will not receive indication >of support in the Open message, and so is expected to not use the feature. > > > >- A PCEP speaker that receives any of the objects that are part of the >feature when use of the feature has not been agreed, will as > described in . > > > > Of course, this is “business as usual” but the reviewer of the text will > not necessarily know this. > > > > Cheers, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 25 August 2021 05:44 > *To:* adr...@olddog.co.uk > *Cc:* Dhruv Dhody ; draft-dhodylee-pce-pcep...@ietf.org; > pce@ietf.org; pce-chairs > *Subject:* Re: draft-dhodylee-pce-pcep-ls next steps! > > > > Hi Adrian > > > > > > See section 1.1 should have answers to your questions related to the > experimental draft. > > > > > https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1 > > > > > Kind Regards > > > > Gyan > > On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel wrote: > > Hi Gyan, > > > > I am very much in favour of positioning this work as Experimental. > > > > It is important (as with all IETF Experiments) to capture: > > - What stops this extension “escaping" in the Internet? > > - What stops this experiment clashing with other work or harming > deployed equipment? > > - How will you judge the success or failure of the experiment, > and when? > > - What follow-up to the experiment do you propose? > > > > Best, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 05 July 2021 07:43 > *To:* Adrian Farrel ; Dhruv Dhody ; > draft-dhodylee-pce-pcep...@ietf.org; pce-chairs ; > pce@ietf.org > *Subject:* draft-dhodylee-pce-pcep-ls next steps! > > > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > From the last query on this draft March 18th we received positive feedback > from Aijun Wang with China Telecom mentioned that as a telco are interest > in deploying in their network PCEP-LS once the Huawei implementation is > ready. Aijun pointed out in the thread that using this draft simplifies > the implementation of SDN controller. One question asked by Aijun was > related to section 9.2.1 LS Capability TLV R=1 remote allowed meaning > hybrid mode to provide flexibility for operators not yet using SDN > (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) > SBI, a direct PCEP session already exist between all the nodes in the > network and the PCE which would be the PCECV SDN scenario in which case the > R flag in the open message is set to 0. > > > > We also received positive feedback from Peter Park with telco KT regarding > interest in PCEP-LS. > > >
Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
Hi Adrian Agreed. We will make it more clear. Many Thanks! Gyan On Wed, Aug 25, 2021 at 10:30 AM Adrian Farrel wrote: > Yes, thanks, Gyan. > > > > I think you have captured it all, although some of the behaviours are > “hidden” in assumptions in the text. > > > > That is: > > > >- A PCEP speaker that offers this feature to its peer that does not >support or does not wish to support the feature will not receive indication >of support in the Open message, and so is expected to not use the feature. > > > >- A PCEP speaker that receives any of the objects that are part of the >feature when use of the feature has not been agreed, will as >described in . > > > > Of course, this is “business as usual” but the reviewer of the text will > not necessarily know this. > > > > Cheers, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 25 August 2021 05:44 > *To:* adr...@olddog.co.uk > *Cc:* Dhruv Dhody ; draft-dhodylee-pce-pcep...@ietf.org; > pce@ietf.org; pce-chairs > *Subject:* Re: draft-dhodylee-pce-pcep-ls next steps! > > > > Hi Adrian > > > > > > See section 1.1 should have answers to your questions related to the > experimental draft. > > > > > https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1 > > > > > Kind Regards > > > > Gyan > > On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel wrote: > > Hi Gyan, > > > > I am very much in favour of positioning this work as Experimental. > > > > It is important (as with all IETF Experiments) to capture: > > - What stops this extension “escaping" in the Internet? > > - What stops this experiment clashing with other work or harming > deployed equipment? > > - How will you judge the success or failure of the experiment, > and when? > > - What follow-up to the experiment do you propose? > > > > Best, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 05 July 2021 07:43 > *To:* Adrian Farrel ; Dhruv Dhody ; > draft-dhodylee-pce-pcep...@ietf.org; pce-chairs ; > pce@ietf.org > *Subject:* draft-dhodylee-pce-pcep-ls next steps! > > > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > From the last query on this draft March 18th we received positive feedback > from Aijun Wang with China Telecom mentioned that as a telco are interest > in deploying in their network PCEP-LS once the Huawei implementation is > ready. Aijun pointed out in the thread that using this draft simplifies > the implementation of SDN controller. One question asked by Aijun was > related to section 9.2.1 LS Capability TLV R=1 remote allowed meaning > hybrid mode to provide flexibility for operators not yet using SDN > (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) > SBI, a direct PCEP session already exist between all the nodes in the > network and the PCE which would be the PCECV SDN scenario in which case the > R flag in the open message is set to 0. > > > > We also received positive feedback from Peter Park with telco KT regarding > interest in PCEP-LS. > > > > We also had feedback from Bin as they have implemented PCEP and have > interest in this experimental implementation of this work. > > > > I would like to poll the WG again for interest in progressing research and > development efforts of this draft as experimental. > > > > As stated in the last WG poll, I would like get feedback from the WG on > scope of experiments especially related to scalability concerns and impact > to other protocols on t
Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
Hi Adrian See section 1.1 should have answers to your questions related to the experimental draft. https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1 Kind Regards Gyan On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel wrote: > Hi Gyan, > > > > I am very much in favour of positioning this work as Experimental. > > > > It is important (as with all IETF Experiments) to capture: > > - What stops this extension “escaping" in the Internet? > > - What stops this experiment clashing with other work or harming > deployed equipment? > > - How will you judge the success or failure of the experiment, > and when? > > - What follow-up to the experiment do you propose? > > > > Best, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 05 July 2021 07:43 > *To:* Adrian Farrel ; Dhruv Dhody ; > draft-dhodylee-pce-pcep...@ietf.org; pce-chairs ; > pce@ietf.org > *Subject:* draft-dhodylee-pce-pcep-ls next steps! > > > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > From the last query on this draft March 18th we received positive feedback > from Aijun Wang with China Telecom mentioned that as a telco are interest > in deploying in their network PCEP-LS once the Huawei implementation is > ready. Aijun pointed out in the thread that using this draft simplifies > the implementation of SDN controller. One question asked by Aijun was > related to section 9.2.1 LS Capability TLV R=1 remote allowed meaning > hybrid mode to provide flexibility for operators not yet using SDN > (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) > SBI, a direct PCEP session already exist between all the nodes in the > network and the PCE which would be the PCECV SDN scenario in which case the > R flag in the open message is set to 0. > > > > We also received positive feedback from Peter Park with telco KT regarding > interest in PCEP-LS. > > > > We also had feedback from Bin as they have implemented PCEP and have > interest in this experimental implementation of this work. > > > > I would like to poll the WG again for interest in progressing research and > development efforts of this draft as experimental. > > > > As stated in the last WG poll, I would like get feedback from the WG on > scope of experiments especially related to scalability concerns and impact > to other protocols on the network. > > > > Thanks! > > Gyan (on behalf of co-authors) > > > > [1] > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf > > [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > == > > > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05
new protocol extension for TCP MD5 support.* > > > > *Best Regards,* > > *Qiufang Ma* > > > > Thanks, > > Ketan > > > > *From:* Lsr *On Behalf Of *Acee Lindem (acee) > *Sent:* 21 July 2021 22:16 > *To:* l...@ietf.org > *Cc:* draft-ietf-lsr-pce-discovery-security-supp...@ietf.org > *Subject:* [Lsr] WG Last Call for IGP extension for PCEP security > capability support in the PCE discovery - > draft-ietf-lsr-pce-discovery-security-support-05 > > > > This begins a 3-week WG Last Call, ending on August 4th, 2021, for > draft-ietf-lsr-pce-discovery-security-support. Please indicate your support > or objection to this list before the end of the WG last call. The longer WG > last call is to account for IETF week. > > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ > > > > > > Thanks, > > Acee > > > > > ___ > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
Thank you Adrian!!! Gyan On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel wrote: > Hi Gyan, > > > > I am very much in favour of positioning this work as Experimental. > > > > It is important (as with all IETF Experiments) to capture: > > - What stops this extension “escaping" in the Internet? > > - What stops this experiment clashing with other work or harming > deployed equipment? > > - How will you judge the success or failure of the experiment, > and when? > > - What follow-up to the experiment do you propose? > > > > Best, > > Adrian > > > > *From:* Gyan Mishra > *Sent:* 05 July 2021 07:43 > *To:* Adrian Farrel ; Dhruv Dhody ; > draft-dhodylee-pce-pcep...@ietf.org; pce-chairs ; > pce@ietf.org > *Subject:* draft-dhodylee-pce-pcep-ls next steps! > > > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > From the last query on this draft March 18th we received positive feedback > from Aijun Wang with China Telecom mentioned that as a telco are interest > in deploying in their network PCEP-LS once the Huawei implementation is > ready. Aijun pointed out in the thread that using this draft simplifies > the implementation of SDN controller. One question asked by Aijun was > related to section 9.2.1 LS Capability TLV R=1 remote allowed meaning > hybrid mode to provide flexibility for operators not yet using SDN > (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) > SBI, a direct PCEP session already exist between all the nodes in the > network and the PCE which would be the PCECV SDN scenario in which case the > R flag in the open message is set to 0. > > > > We also received positive feedback from Peter Park with telco KT regarding > interest in PCEP-LS. > > > > We also had feedback from Bin as they have implemented PCEP and have > interest in this experimental implementation of this work. > > > > I would like to poll the WG again for interest in progressing research and > development efforts of this draft as experimental. > > > > As stated in the last WG poll, I would like get feedback from the WG on > scope of experiments especially related to scalability concerns and impact > to other protocols on the network. > > > > Thanks! > > Gyan (on behalf of co-authors) > > > > [1] > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf > > [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > == > > > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
Hi Siva Many thanks for your support and responding to WG poll sent for interest in progressing research and development efforts of this work as as an experimental draft. Yes that is one of the main R=0 goals and use cases to be able to reuse the existing PCECC CCI object SDN (SDN-like) SBI session for PCEP-LS, thereby eliminating the needs for another protocol in this case BGP-LS NBI for that purpose. That is the main goal and use case and very nicely pointed out Siva. This draft does provide the nice flexibility as well if operators are not yet using PCECC for R=1, to allow for mixed environments and cater to the operators needs and requirements. We want to emphasize that we are not trying to by any means compete with the other existing solutions but rather provide operators another valuable tool in the operators toolbox. As part of the next steps in building the framework for the scope of the experiments performed the to prove out any scalability concerns and impact to other protocols namely the reuse aspect of the SBI. We would like to prove out that this solution is solid and viable in the tests and that the reuse of the SBI in fact provides improves scalability rather than diminishing scalability by leveraging the R=0 existing sessions between all nodes versus PCEP PCE R=1. We would also like to prove out in the experiment that we are in fact not overloading the SBI by the reuse for PCEP-LS and in no way impacting the existing SBI PCECC PCE session. We would like to address in the experiment any and all scalability, overload, collateral damage related issues or any fear or issues anyone has to prove that this is a solid and viable solution on par with the other existing solutions as an extra tool in the operators toolbox. Kind Regards Gyan On Sun, Jul 18, 2021 at 8:43 AM Siva Sivabalan wrote: > Hi Gyan, > > I support this experimental work. If a router communicates with PCE over > PCEP for path computation purpose, it might as well propagate topology via > PCEP eliminating the need for another protocol for that purpose. The lesser > the number of protocols, the better for simplifying network operation. > > Thanks, > Siva > > > On Mon, Jul 5, 2021 at 2:43 AM Gyan Mishra wrote: > >> >> Dear PCE WG, >> >> >> We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap >> and a summary of past discussions. Some new scenarios such as PCECC, H-PCE >> were highlighted where the PCEP session could be reused. >> >> >> This is an experimental I-D with the aim to progress research and >> development efforts. This work is not a replacement for any of the existing >> mechanisms. There are specific scenarios highlighted where the reuse of >> PCEP sessions for this information is deemed useful. To make progress, it >> may not be useful to rehash the beauty context between everyone's favorite >> protocol :). What would be useful would be - finding out if there is still >> interest in this experimental work by some in the WG; are there strong >> technical objections for the experiment in its limited scope etc... >> >> >> As a next step, it would be good to define the scope of the experiments >> and expected output especially targeting the scalability concerns as well >> as impact in other protocols and the network, etc. >> >> >> From the last query on this draft March 18th we received positive >> feedback from Aijun Wang with China Telecom mentioned that as a telco are >> interest in deploying in their network PCEP-LS once the Huawei >> implementation is ready. Aijun pointed out in the thread that using this >> draft simplifies the implementation of SDN controller. One question asked >> by Aijun was related to section 9.2.1 LS Capability TLV R=1 remote allowed >> meaning hybrid mode to provide flexibility for operators not yet using SDN >> (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) >> SBI, a direct PCEP session already exist between all the nodes in the >> network and the PCE which would be the PCECV SDN scenario in which case the >> R flag in the open message is set to 0. >> >> >> We also received positive feedback from Peter Park with telco KT >> regarding interest in PCEP-LS. >> >> >> We also had feedback from Bin as they have implemented PCEP and have >> interest in this experimental implementation of this work. >> >> >> I would like to poll the WG again for interest in progressing research >> and development efforts of this draft as experimental. >> >> >> As stated in the last WG poll, I would like get feedback from the WG on >> scope of experiments especially related to scalability concerns and impact >&g
[Pce] draft-dhodylee-pce-pcep-ls next steps!
Dear PCE WG, We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a summary of past discussions. Some new scenarios such as PCECC, H-PCE were highlighted where the PCEP session could be reused. This is an experimental I-D with the aim to progress research and development efforts. This work is not a replacement for any of the existing mechanisms. There are specific scenarios highlighted where the reuse of PCEP sessions for this information is deemed useful. To make progress, it may not be useful to rehash the beauty context between everyone's favorite protocol :). What would be useful would be - finding out if there is still interest in this experimental work by some in the WG; are there strong technical objections for the experiment in its limited scope etc... As a next step, it would be good to define the scope of the experiments and expected output especially targeting the scalability concerns as well as impact in other protocols and the network, etc. >From the last query on this draft March 18th we received positive feedback from Aijun Wang with China Telecom mentioned that as a telco are interest in deploying in their network PCEP-LS once the Huawei implementation is ready. Aijun pointed out in the thread that using this draft simplifies the implementation of SDN controller. One question asked by Aijun was related to section 9.2.1 LS Capability TLV R=1 remote allowed meaning hybrid mode to provide flexibility for operators not yet using SDN (SDN-like) SBI. For any operators already using PCEP as SDN (SDN-like) SBI, a direct PCEP session already exist between all the nodes in the network and the PCE which would be the PCECV SDN scenario in which case the R flag in the open message is set to 0. We also received positive feedback from Peter Park with telco KT regarding interest in PCEP-LS. We also had feedback from Bin as they have implemented PCEP and have interest in this experimental implementation of this work. I would like to poll the WG again for interest in progressing research and development efforts of this draft as experimental. As stated in the last WG poll, I would like get feedback from the WG on scope of experiments especially related to scalability concerns and impact to other protocols on the network. Thanks! Gyan (on behalf of co-authors) [1] https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ == <http://www.verizon.com/> *Gyan Mishra* *Network Solutions Architect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption of draft-litkowski-pce-state-sync
I support WG adoption. Kind Regards Gyan On Wed, May 26, 2021 at 12:22 AM Pengshuping (Peng Shuping) < pengshup...@huawei.com> wrote: > Hi WG, > > I support the adoption of this work. > > Best regards, > Shuping > > > > -Original Message- > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of > > julien.meu...@orange.com > > Sent: Monday, May 17, 2021 9:41 PM > > To: pce@ietf.org > > Subject: [Pce] Adoption of draft-litkowski-pce-state-sync > > > > Dear all, > > > > The document draft-litkowski-pce-state-sync has reached the head of our > > adoption queue > > (https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/). > > > > Do you consider this I-D is a good foundation for a WG item? Please share > > your feedback using the PCE mailing list by May 31. > > > > Regards, > > > > Dhruv & Julien > > > > _______ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05
I am interested in working on this draft. Thanks Gyan On Wed, Apr 14, 2021 at 11:21 PM Gyan Mishra wrote: > > I support WG adoption of this important draft for instantiation of ECMP > multipath by encoding multiple segments lists of an SR candidate path. > > Gyan > > On Wed, Apr 14, 2021 at 8:50 PM Tarek Saad wrote: > >> I support adoption of this draft as coauthor. This is important to >> support the signaling of multi path LSP with per path attributes in PCEP. >> >> Regards, >> Tarek >> >> Sent from my iPhone >> >> On Apr 14, 2021, at 10:53 AM, Dhruv Dhody wrote: >> >> >> >> Hi WG, >> >> This email begins the WG adoption poll for >> draft-koldychev-pce-multipath-05. >> >> https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05 >> >> 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. >> >> Please respond by Wednesday 28th April. >> >> 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 >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com * > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05
I support WG adoption of this important draft for instantiation of ECMP multipath by encoding multiple segments lists of an SR candidate path. Gyan On Wed, Apr 14, 2021 at 8:50 PM Tarek Saad wrote: > I support adoption of this draft as coauthor. This is important to support > the signaling of multi path LSP with per path attributes in PCEP. > > Regards, > Tarek > > Sent from my iPhone > > On Apr 14, 2021, at 10:53 AM, Dhruv Dhody wrote: > > > > Hi WG, > > This email begins the WG adoption poll for > draft-koldychev-pce-multipath-05. > > https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05 > > 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. > > Please respond by Wednesday 28th April. > > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn
Hi Peter That’s good to hear interest from operators such as yourself in PCEP-LS. As you deploy PCECC and H-PCE in a multi domain environments you will be able to reuse the SBI PCEP session for PCEP-LS and then can take full advantage of some of benefits of PCEP-LS such as synchronization optimization and incremental updates. Thank you for sharing your interest in PCEP-LS. Kind Regards Gyan On Thu, Apr 1, 2021 at 9:14 PM 박춘걸(Naas Transformation 팀) wrote: > Dear Gyan, > > > > As a telco, we are interested in the upgrade of PCEP. > > PCEP and H-PCE scenarios is always being considered as valuable tools for > solving our issues in telco’s multi-domain environment. > > > > Regards, > > Peter > > > > > > *From:* Gyan Mishra > *Sent:* Thursday, March 18, 2021 11:36 AM > *To:* pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody < > d...@dhruvdhody.com>; Adrian Farrel > *Subject:* [Pce] draft-dhodylee-pce-pcep-te-data-extn > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > Thanks! > > Gyan (on behalf of co-authors) > > > > [1] > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf > > [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > == > > > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > > > > > 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 > 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 > 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다. > This E-mail may contain confidential information and/or copyright > material. This email is intended for the use of the addressee only. If you > receive this email by mistake, please either delete it without reproducing, > distributing or retaining copies thereof or notify the sender immediately. > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn
Hi Aijun That’s great to here interest from operators in PCEP-LS! Kind Regards Gyan On Thu, Apr 1, 2021 at 9:30 PM Aijun Wang wrote: > Hi, > > > > Also as a telco, we are expecting the implementation of PCEP-LS, and once > it is ready, we will try to deploy it in the network. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* pce-boun...@ietf.org *On Behalf Of *???(Naas > Transformation ?) > *Sent:* Friday, April 2, 2021 9:14 AM > *To:* Gyan Mishra ; pce@ietf.org; > draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody ; > Adrian Farrel > *Subject:* Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn > > > > Dear Gyan, > > > > As a telco, we are interested in the upgrade of PCEP. > > PCEP and H-PCE scenarios is always being considered as valuable tools for > solving our issues in telco’s multi-domain environment. > > > > Regards, > > Peter > > > > > > *From:* Gyan Mishra > *Sent:* Thursday, March 18, 2021 11:36 AM > *To:* pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody < > d...@dhruvdhody.com>; Adrian Farrel > *Subject:* [Pce] draft-dhodylee-pce-pcep-te-data-extn > > > > Dear PCE WG, > > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > > Thanks! > > Gyan (on behalf of co-authors) > > > > [1] > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf > > [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > == > > > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > > > > > > > 이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 > 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 > 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다. > This E-mail may contain confidential information and/or copyright > material. This email is intended for the use of the addressee only. If you > receive this email by mistake, please either delete it without reproducing, > distributing or retaining copies thereof or notify the sender immediately. > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] draft-dhodylee-pce-pcep-te-data-extn
Thank you Bin for your sharing your positive experience with PCEP-LS in the field and continued experimenting in scenarios such as H-PCE and PCECC. Thank you for supporting this experimental draft and interest in progressing. Kind Regards Gyan On Thu, Apr 1, 2021 at 1:00 AM 윤빈영 wrote: > Hi Gyan, > > > We have implemented PCEP in the past. > > This experimental upgrade of PCEP to enable direct TE updates to PCE is > worth to try and we'd be interested in the implementation of this work. > > > Regards, > > Bin > > > *From:* Gyan Mishra > *Sent:* Thursday, March 18, 2021 11:36 AM > *To:* pce@ietf.org; draft-dhodylee-pce-pcep...@ietf.org; Dhruv Dhody < > d...@dhruvdhody.com>; Adrian Farrel > *Subject:* [Pce] draft-dhodylee-pce-pcep-te-data-extn > > > Dear PCE WG, > > > We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap > and a summary of past discussions. Some new scenarios such as PCECC, H-PCE > were highlighted where the PCEP session could be reused. > > > This is an experimental I-D with the aim to progress research and > development efforts. This work is not a replacement for any of the existing > mechanisms. There are specific scenarios highlighted where the reuse of > PCEP sessions for this information is deemed useful. To make progress, it > may not be useful to rehash the beauty context between everyone's favorite > protocol :). What would be useful would be - finding out if there is still > interest in this experimental work by some in the WG; are there strong > technical objections for the experiment in its limited scope etc... > > > As a next step, it would be good to define the scope of the experiments > and expected output especially targeting the scalability concerns as well > as impact in other protocols and the network, etc. > > > Thanks! > > Gyan (on behalf of co-authors) > > > [1] > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf > > [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ > > == > > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com * > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Understood. I-D covers only BSID control plane handling for both RSVP-TE and SR-TE However, for RSVP-TE their is only a control plane component where SR both control and data plane of which the SR-MPLS and SRv6 data plane is handled in SPRING/MPLS/6MAN. Gyan On Mon, Mar 29, 2021 at 10:07 AM Siva Sivabalan wrote: > +1 > > On Mon, Mar 29, 2021 at 10:06 AM Dhruv Dhody wrote: > >> Hi Gyan, >> >> As a WG member... >> >> IMHO PCE I-D should not go into the data-plane handling of BSID, that is >> SPRING/MPLS/6MAN perview. >> >> Thanks! >> Dhruv >> >> >> On Mon, Mar 29, 2021 at 7:21 PM Gyan Mishra >> wrote: >> >>> Hi Mike >>> >>> Is the usage for BSID only for control plane signaling as I described >>> it. >>> >>> What other use cases exist and maybe we should add to the draft. >>> >>> Thanks >>> >>> Gyan >>> >>> On Mon, Mar 29, 2021 at 4:50 AM Mike Koldychev (mkoldych) < >>> mkold...@cisco.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> I think that BSID is a concept that applies equally well to RSVP-TE and >>>> SR-TE. There are many use-cases for RSVP tunnels having a BSID and we >>>> definitely DO NOT want to limit it to just SR-TE. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Mike. >>>> >>>> >>>> >>>> *From:* Pce *On Behalf Of * Gyan Mishra >>>> *Sent:* Sunday, March 28, 2021 7:53 PM >>>> *To:* Siva Sivabalan >>>> *Cc:* pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; Stone, >>>> Andrew (Nokia - CA/Ottawa) >>>> *Subject:* Re: [Pce] WG Last Call for >>>> draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation) >>>> >>>> >>>> >>>> >>>> >>>> Hi Siva >>>> >>>> >>>> >>>> I believe I was missing the signaling aspect for the PCE to build the >>>> contiguous end to end LSP and that requires BSID to be signaled over >>>> RSVP-TE which is although agnostic to data plane BSID component binding the >>>> candidate path to the forwarding plane, is a requirement for end to end >>>> control plane signaling for the single LSP end to end path instantiation. >>>> >>>> >>>> >>>> The BSID signaling concept is somewhat analogous concept to LDP >>>> tunneling over RSVP-TE tunnel stitching for an end to end LSP >>>> instantiation. >>>> >>>> >>>> >>>> Thank you Siva for the clarification. >>>> >>>> >>>> >>>> Gyan >>>> >>>> >>>> >>>> On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan >>>> wrote: >>>> >>>> Hi Gyan, >>>> >>>> >>>> >>>> This ID is all about signaling BSID for RSVP-TE tunnels and SR policies >>>> via PCEP. >>>> >>>> >>>> >>>> Please do not confuse signaling aspects with how BSID is used. >>>> >>>> >>>> >>>> There is no change required in the ID. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Siva >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra >>>> wrote: >>>> >>>> >>>> >>>> All >>>> >>>> >>>> >>>> After further review with Siva the use case is for connecting SR >>>> islands over RSVP-TE core. >>>> >>>> >>>> >>>> So this is for stitching SR-TE on the edge islands binding SID to core >>>> RSVP-TE tunnel. >>>> >>>> >>>> >>>> One major gap of RSVP-TE is the VRF / VPN coloring capability that in >>>> order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel >>>> requires a separate loopback and static routes to egress PE so it does not >>>> scale. So for as many RSVP mapped tunnels that exist you need that many >>>> loopbacks and static routes for the next hop rewrite to the RSVP tunnel >>>> next hop. >>>> >>>> >>>> >>>&g
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi Mike Is the usage for BSID only for control plane signaling as I described it. What other use cases exist and maybe we should add to the draft. Thanks Gyan On Mon, Mar 29, 2021 at 4:50 AM Mike Koldychev (mkoldych) < mkold...@cisco.com> wrote: > Hi, > > > > I think that BSID is a concept that applies equally well to RSVP-TE and > SR-TE. There are many use-cases for RSVP tunnels having a BSID and we > definitely DO NOT want to limit it to just SR-TE. > > > > Thanks, > > Mike. > > > > *From:* Pce *On Behalf Of * Gyan Mishra > *Sent:* Sunday, March 28, 2021 7:53 PM > *To:* Siva Sivabalan > *Cc:* pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; Stone, > Andrew (Nokia - CA/Ottawa) > *Subject:* Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 > (and Code Point Allocation) > > > > > > Hi Siva > > > > I believe I was missing the signaling aspect for the PCE to build the > contiguous end to end LSP and that requires BSID to be signaled over > RSVP-TE which is although agnostic to data plane BSID component binding the > candidate path to the forwarding plane, is a requirement for end to end > control plane signaling for the single LSP end to end path instantiation. > > > > The BSID signaling concept is somewhat analogous concept to LDP tunneling > over RSVP-TE tunnel stitching for an end to end LSP instantiation. > > > > Thank you Siva for the clarification. > > > > Gyan > > > > On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan wrote: > > Hi Gyan, > > > > This ID is all about signaling BSID for RSVP-TE tunnels and SR policies > via PCEP. > > > > Please do not confuse signaling aspects with how BSID is used. > > > > There is no change required in the ID. > > > > Thanks, > > Siva > > > > > > On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra wrote: > > > > All > > > > After further review with Siva the use case is for connecting SR islands > over RSVP-TE core. > > > > So this is for stitching SR-TE on the edge islands binding SID to core > RSVP-TE tunnel. > > > > One major gap of RSVP-TE is the VRF / VPN coloring capability that in > order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel > requires a separate loopback and static routes to egress PE so it does not > scale. So for as many RSVP mapped tunnels that exist you need that many > loopbacks and static routes for the next hop rewrite to the RSVP tunnel > next hop. > > > > So this Major gap is filled with SR VRF and app flow coloring capability > that with SR-TE Policy BSID bound to candidate path can provide the > scalability per VRF coloring. > > > > So at the edges you may have many 100s of colored RSVP tunnels but as the > core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to > RSVP tunnel. So you would have many to 1 mappings of SR-TE tunnels to > single or aggregate. > > > > So in my mind to only way the BSID would come into play is if you could do > a 1-1 mapping of SR-TE tunnel to RSVP tunnel. Technically that is not > possible. > > > > For PCE to compute end to end path in this scenario does RSVP-TE require > the BSID for the stitching even if a many SR-TE colors to single RSVP-TE > tunnel mapping. I would not think so. > > > > If we think that for PCE to build the end to end path even for the end to > end path in this scenario requires BSID binding to the RSVP-TE single path > to make contiguous end to end then I agree technically we do need to make > this inclusive of RSVP-TE. > > > > I think we need to clear this up and if this use case is really not > feasible then we should remove any mention of BSID use with RSVP-TE tunnel. > > > > Kind Regards > > > > Gyan > > > > On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan wrote: > > Hi Gyan, > > > > BSID can be allocated for RSVP-TE as well, and yes, there are use-cases > for that. The proposed PCEP extension is equally applicable to both SR-TE > and RSVP-TE. > > > > Thanks, > > Siva > > > > On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra wrote: > > > > > > I support WG LC advancement of this draft for publication. > > > > I see there are a lot of comments related to a mix of verbiage related to > MPLS label binding and Binding label SID confusion. > > > > Few comments. > > > > The draft title states “carrying binding label/sid in PCE based networks” > > > > In the abstract it states it is possible to associate a BSID with a RSVP > signaled path. > > &g
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Hi Siva I believe I was missing the signaling aspect for the PCE to build the contiguous end to end LSP and that requires BSID to be signaled over RSVP-TE which is although agnostic to data plane BSID component binding the candidate path to the forwarding plane, is a requirement for end to end control plane signaling for the single LSP end to end path instantiation. The BSID signaling concept is somewhat analogous concept to LDP tunneling over RSVP-TE tunnel stitching for an end to end LSP instantiation. Thank you Siva for the clarification. Gyan On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan wrote: > Hi Gyan, > > This ID is all about signaling BSID for RSVP-TE tunnels and SR policies > via PCEP. > > Please do not confuse signaling aspects with how BSID is used. > > There is no change required in the ID. > > Thanks, > Siva > > > On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra wrote: > >> >> All >> >> After further review with Siva the use case is for connecting SR islands >> over RSVP-TE core. >> >> So this is for stitching SR-TE on the edge islands binding SID to core >> RSVP-TE tunnel. >> >> One major gap of RSVP-TE is the VRF / VPN coloring capability that in >> order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel >> requires a separate loopback and static routes to egress PE so it does not >> scale. So for as many RSVP mapped tunnels that exist you need that many >> loopbacks and static routes for the next hop rewrite to the RSVP tunnel >> next hop. >> >> So this Major gap is filled with SR VRF and app flow coloring capability >> that with SR-TE Policy BSID bound to candidate path can provide the >> scalability per VRF coloring. >> >> So at the edges you may have many 100s of colored RSVP tunnels but as the >> core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to >> RSVP tunnel. So you would have many to 1 mappings of SR-TE tunnels to >> single or aggregate. >> >> So in my mind to only way the BSID would come into play is if you could >> do a 1-1 mapping of SR-TE tunnel to RSVP tunnel. Technically that is not >> possible. >> >> For PCE to compute end to end path in this scenario does RSVP-TE require >> the BSID for the stitching even if a many SR-TE colors to single RSVP-TE >> tunnel mapping. I would not think so. >> >> If we think that for PCE to build the end to end path even for the end to >> end path in this scenario requires BSID binding to the RSVP-TE single path >> to make contiguous end to end then I agree technically we do need to make >> this inclusive of RSVP-TE. >> >> I think we need to clear this up and if this use case is really not >> feasible then we should remove any mention of BSID use with RSVP-TE tunnel. >> >> Kind Regards >> >> Gyan >> >> On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan >> wrote: >> >>> Hi Gyan, >>> >>> BSID can be allocated for RSVP-TE as well, and yes, there are use-cases >>> for that. The proposed PCEP extension is equally applicable to both SR-TE >>> and RSVP-TE. >>> >>> Thanks, >>> Siva >>> >>> On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra >>> wrote: >>> >>>> >>>> >>>> I support WG LC advancement of this draft for publication. >>>> >>>> I see there are a lot of comments related to a mix of verbiage related >>>> to MPLS label binding and Binding label SID confusion. >>>> >>>> Few comments. >>>> >>>> The draft title states “carrying binding label/sid in PCE based >>>> networks” >>>> >>>> In the abstract it states it is possible to associate a BSID with a >>>> RSVP signaled path. >>>> >>>> I don’t recall any RSVP extension to support concept of BSID usage on >>>> an active Candidate Path option ERO. Can you refer me to the RFC that >>>> states how BSID is used with RSVP TE. >>>> >>>> For more clarity with this draft can we replace >>>> >>>> s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion >>>> where SR is SR. When mentioned traffic engineered path please spell out or >>>> say SR path for clarity. >>>> >>>> Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”. >>>> >>>> The word “binding” is very confusing as it’s used interchangeably with >>>> label binding and binding SID. >>>> >>
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
All After further review with Siva the use case is for connecting SR islands over RSVP-TE core. So this is for stitching SR-TE on the edge islands binding SID to core RSVP-TE tunnel. One major gap of RSVP-TE is the VRF / VPN coloring capability that in order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel requires a separate loopback and static routes to egress PE so it does not scale. So for as many RSVP mapped tunnels that exist you need that many loopbacks and static routes for the next hop rewrite to the RSVP tunnel next hop. So this Major gap is filled with SR VRF and app flow coloring capability that with SR-TE Policy BSID bound to candidate path can provide the scalability per VRF coloring. So at the edges you may have many 100s of colored RSVP tunnels but as the core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to RSVP tunnel. So you would have many to 1 mappings of SR-TE tunnels to single or aggregate. So in my mind to only way the BSID would come into play is if you could do a 1-1 mapping of SR-TE tunnel to RSVP tunnel. Technically that is not possible. For PCE to compute end to end path in this scenario does RSVP-TE require the BSID for the stitching even if a many SR-TE colors to single RSVP-TE tunnel mapping. I would not think so. If we think that for PCE to build the end to end path even for the end to end path in this scenario requires BSID binding to the RSVP-TE single path to make contiguous end to end then I agree technically we do need to make this inclusive of RSVP-TE. I think we need to clear this up and if this use case is really not feasible then we should remove any mention of BSID use with RSVP-TE tunnel. Kind Regards Gyan On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan wrote: > Hi Gyan, > > BSID can be allocated for RSVP-TE as well, and yes, there are use-cases > for that. The proposed PCEP extension is equally applicable to both SR-TE > and RSVP-TE. > > Thanks, > Siva > > On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra wrote: > >> >> >> I support WG LC advancement of this draft for publication. >> >> I see there are a lot of comments related to a mix of verbiage related to >> MPLS label binding and Binding label SID confusion. >> >> Few comments. >> >> The draft title states “carrying binding label/sid in PCE based networks” >> >> In the abstract it states it is possible to associate a BSID with a RSVP >> signaled path. >> >> I don’t recall any RSVP extension to support concept of BSID usage on an >> active Candidate Path option ERO. Can you refer me to the RFC that states >> how BSID is used with RSVP TE. >> >> For more clarity with this draft can we replace >> >> s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion >> where SR is SR. When mentioned traffic engineered path please spell out or >> say SR path for clarity. >> >> Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”. >> >> The word “binding” is very confusing as it’s used interchangeably with >> label binding and binding SID. >> >> So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID >> TLV”. Makes it clear and concise the TLV is for SR-TE. >> >> Kind Regards >> >> Gyan >> >> On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) >> wrote: >> >>> Thanks again for your help! >>> >>> Cheng >>> >>> >>> >>> -Original Message- >>> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] >>> Sent: Saturday, March 27, 2021 2:42 AM >>> To: Chengli (Cheng Li) ; julien.meu...@orange.com; >>> pce@ietf.org >>> Cc: draft-ietf-pce-binding-label-...@ietf.org >>> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 >>> (and Code Point Allocation) >>> >>> Hi Cheng, >>> >>> Thanks for clarifying the text in the document. Diff content looks good >>> to me, much clearer. Consider my comments resolved. >>> >>> Thanks! >>> Andrew >>> >>> On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" < >>> pce-boun...@ietf.org on behalf of c...@huawei.com> wrote: >>> >>> Hi Andrew, >>> >>> Thanks for your comments, please see my reply inline. >>> >>> Also, the diff is attached. >>> >>> Respect, >>> Cheng >>> >>> >>> >>> >>> -Original Message- >>> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto: >>> andrew.st...@no
Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
- CA/Ottawa) >> *Cc:* pce@ietf.org >> *Subject:* Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and >> action. >> >> >> >> Hi Hooman, >> >> >> >> On Thu, Mar 18, 2021 at 10:06 PM Bidgoli, Hooman (Nokia - CA/Ottawa) < >> hooman.bidg...@nokia.com> wrote: >> >> Hi Dhruv >> >> I am very confused by your messaging. >> >> Originally it was pointed out that the draft should follow PCECC/CCI. >> The authors explained why they feel that is not a good fit. >> >> Now you are mentioning get in part with RFC 8231, 8281 etc... which is a >> new input. Thank you. >> >> >> >> I apologize if I was not clear. As I said in the mail, I still feel PCECC >> is the way to go. What I want to highlight is that if you consider it as an >> LSP operation instead, then it should be built on RFC 8623 (P2MP) instead. >> >> >> >> The 'recap' was to show how the extensions in PCEP have been done for SR >> and P2MP in the past in a consistent way. >> >> >> >> >> >> The authors/co-authors have tried to keep the draft in par with all the >> RFCs that you mentioned as much as possible. As it is mentioned in the >> draft clearly. That said this is new concept and there is a need for a new >> PCE concept and deviation, hence the draft and the purpose of IETF. >> >> RSVP-TE P2MP is built via S2Ls. >> Replication segment is nothing like S2L, replication segment can be >> connected via unicast SR. >> >> >> >> If you claim that the replication segment can not use RFC 8623, that >> gives it more of a reason to not consider it as an LSP operation in the >> first place. >> >> >> >> Again we are open for any constructive feedback on how this draft can be >> improved, in the boundary of >> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ >> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ >> >> >> >> Just to clarify, my feedback is on your choice of PCEP procedure and >> encoding for the replication segment taking existing PCEP >> extensions/procedures in mind. Hope the discussion was useful, it was for >> me... >> >> >> >> Thanks! >> >> Dhruv (as a WG member) >> >> >> >> Regards >> Hooman >> >> >> -Original Message- >> From: Pce On Behalf Of Dhruv Dhody >> Sent: Thursday, March 18, 2021 8:01 AM >> To: pce@ietf.org >> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action. >> >> Hi, >> >> Speaking as a WG member... >> >> Let's continue the discussion on considering the replication segment as >> an LSP v/s PCECC operation. >> >> I just wanted to quickly recap - >> >> - We have stateful operations for RSVP-TE: RFC 8231, RFC 8281 >> - We then introduced SR with a minimal extension of new PST and a new >> SR-ERO subobject: RFC 8664 >> - We supported P2MP stateful operations for RSVP-TE with RBNF change in >> PCEP messages: RFC 8623 >> >> We have always tried our best to maintain consistency between RSVP-TE and >> SR in PCEP. >> >> Now, if one considers the Replication segment as an LSP operation, IMHO >> it needs to be built on RFC 8623 P2MP LSP operations. The current approach >> does not build on RFC 8623 instead uses the multi-path technique (related >> to ECMP in P2P [1]). This would deviate from RFC >> 8623 significantly. >> >> On the other hand, considering the replication segment as a PCECC/CCI >> operation gives you more leeway to choose an encoding with a new CCI Object >> type for the replication segment and it could be independent of RFC 8623. >> >> I *still* feel PCECC makes more sense at the higher level too (because of >> the additional instruction to the leaves and coordination required). Even >> if one disagrees with that and considers it an LSP operation, it then needs >> to build on RFC 8623. The current "mashup" >> approach (i.e. it is an LSP operation but does not follow P2MP LSP >> encoding) does not work well in maintaining consistency within our >> extensions. >> >> Thanks! >> Dhruv (as a WG member) >> [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/ >> >> ___ >> 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
e on behalf of julien.meu...@orange.com" < > pce-boun...@ietf.org on behalf of julien.meu...@orange.com> wrote: > > Hi all, > > This message initiates a 2-week PCE WG Last Call for > draft-ietf-pce-binding-label-sid-07. Please review and share your > feedback, whatever it is, using the PCE mailing list. This WGLC > will end > on Thursday April 1st (no kidding). > > > Moreover, we have received a request from the authors for a code > point > allocation to support interoperability testing. > > RFC 7120 requires to meet the following criteria to proceed: > > b. The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet-Draft. > c. The specifications of these code points must be stable; i.e., if > there is a change, implementations based on the earlier and later > specifications must be seamlessly interoperable. > > If anyone believes that the draft does not meet these criteria, or > believes that early allocation is not appropriate for any other > reason, please send an email to the PCE mailing list explaining > why. If > the chairs hear no objections by Thursday, March 25th, we will > kick off > the "early" allocation request. > > Thanks, > > Dhruv & Julien > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without > authorisation. > If you have received this email in error, please notify the sender > and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > Thank you. > > ___ > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] draft-dhodylee-pce-pcep-te-data-extn
Dear PCE WG, We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a summary of past discussions. Some new scenarios such as PCECC, H-PCE were highlighted where the PCEP session could be reused. This is an experimental I-D with the aim to progress research and development efforts. This work is not a replacement for any of the existing mechanisms. There are specific scenarios highlighted where the reuse of PCEP sessions for this information is deemed useful. To make progress, it may not be useful to rehash the beauty context between everyone's favorite protocol :). What would be useful would be - finding out if there is still interest in this experimental work by some in the WG; are there strong technical objections for the experiment in its limited scope etc... As a next step, it would be good to define the scope of the experiments and expected output especially targeting the scalability concerns as well as impact in other protocols and the network, etc. Thanks! Gyan (on behalf of co-authors) [1] https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ == <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11
Hi Shuping I reviewed the updated version and it looks good ready for publication. Kind Regards Gyan On Thu, Feb 11, 2021 at 3:50 AM Pengshuping (Peng Shuping) < pengshup...@huawei.com> wrote: > Hi Gyan, > > Many thanks for your review. Please find my responses inline below. > > I have also uploaded the new version of this draft according to your > reviews and suggestions. . > > > https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12 > > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12 > > Please let us know if there is any further comments. > > Thank you! > > > -Original Message- > > From: Gyan Mishra via Datatracker [mailto:nore...@ietf.org] > > Sent: Thursday, February 11, 2021 7:03 AM > > To: gen-...@ietf.org > > Cc: draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org; > > last-c...@ietf.org; pce@ietf.org > > Subject: Genart last call review of > > draft-ietf-pce-pcep-extension-for-pce-controller-11 > > > > Reviewer: Gyan Mishra > > Review result: Almost Ready > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review > > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > > the IETF Chair. Please treat these comments just like any other last > call > > comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-pce-pcep-extension-for-pce-controller-?? > > Reviewer: Gyan Mishra > > Review Date: 2021-02-10 > > IETF LC End Date: 2021-02-08 > > IESG Telechat date: 2021-02-25 > > > > Summary: > > This document is very well written and describes a new PCEP protocol > > extension for using PCE as a centralized controller PCECC for > provisioning > > using its own discrete label space for all or discrete parts static LSP > ERO > > path. > > > > Major issues: > > None > > > > Minor issues: > > > > For stateful PCE how do you prevent label collisions when both the PCE is > > provisioning using its own label space and the routers also are using > their > > own label space as well and have a mix of both. After the label download > > and sync at each router hop PCE PCC session their maybe some nodes that > > use the router label space and other nodes using PCE label space. > > > > This is covered in Section 3, I have added text to clarify further - > >As per Section 3.1.2. of [RFC8283], the PCE-based controller will >take responsibility for managing some part of the MPLS label space >for each of the routers that it controls, and may take wider >responsibility for partitioning the label space for each router and >allocating different parts for different uses. The PCC MUST NOT make >allocations from the label space set aside for the PCE to avoid >overlap and collisions of label allocations. > > > > It would seem more complicated to have a mix of having both PCE managed > > label space and non PCE managed label space and for this draft since it’s > > about provisioning static LSP using PCE discrete label space I think it > would > > make more sense to have entire LSP to be provisioned using PCE label > space > > to prevent label collisions. This caveat I think should be added to the > > considerations section as well. > > OK, I have added - > >It is RECOMMENDED that >PCE makes allocations (from the label space set aside for the PCE) >for all nodes along the path. > > > > I did not see it mentioned but I think it’s > > also worthwhile mentioning what is the advantage of using this extension > > where the PCE uses its own label space. Also list the disadvantages as > well > > so the operator had a clear picture of reasons to use this extension and > > maybe reasons to not use. It maybe also worthwhile to mention use cases > > where it makes sense to use this extension and others where it is not. > > > I have added the following text, which includes the correct references - > >[RFC8283] examines the motivations and applicability for PCECC and >use of PCEP as an SBI. Section 3.1.2. of [RFC8283] highlights the >use of PCECC for label allocation along the static LSPs and it >simplifies the processing of a distributed control plane by blending >it with elements of SDN and without necessarily completely replacing >it. This allows the operator to introduce the advantages of SDN >(such as programmability) into
Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
I support WG adoption by the PCE WG. I agree with Dhruv that maybe we should limit TLV to LSP object only. I don’t mind complexity if their is a significant gain with making it generic. I think we have to weigh the pros and cons. Thanks Gyan On Fri, Feb 5, 2021 at 3:48 AM Dhruv Dhody wrote: > Hi, > > While it is an interesting idea to make this generic, I think we should > limit this TLV to be used with the LSP object only to keep this focused and > avoid complexity. > > Regarding sending errors, I don't think we have specified such an error > before for any other TLVs which are specific to an Object. Applying the > robustness principle and ignoring the TLV (if received in other > objects) would make sense IMHO. > > Thanks! > Dhruv (as a WG member) > > On Fri, Feb 5, 2021 at 12:17 PM wrote: > >> >> Hi Cyril, >> >> >> Thanks for your review and comments! It is a good point. >> >> In my opinion, the TLV and the flag could be used in other PCEP Objects. >> >> But if the defination of extended flags are different, then the TLV is >> different. >> >> I think that would be a new TLV, not the LSP-EXTENDED-FLAG TLV. >> >> What are the thoughts of others? >> >> >> Thanks, >> >> Quan >> >> >> >> >> >> >Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03 >> >> Cyril Margaria Thu, 04 February 2021 10:36 UTCShow >> header >> <https://mailarchive.ietf.org/arch/msg/pce/jL4ZD31H1ZUWSvjItgwQItZ2pjw/#> >> >> Support, >> >> I have the following comments: >> - The TLV is, as specified, is not forbidden in other PCEP Objects, >> - It might be only defined as LSP object TLV and error code defined for >> other cases, but it could also be allowed in any object and the extended >> flags defined themselves within the context of an object. >> >> BR >> Cyril >> >> On Thu, 4 Feb 2021 at 09:14, Dhruv Dhody wrote: >> >> > Hi WG, >> > >> > Greg, Quan, and I discussed this offline and have this proposed text - >> > >> > Note that, PCEP peers MAY encounter different length of the >> > LSP-EXTENDED-FLAG TLV. >> > >> >o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV >> > of a length more than it currently supports or understands, >> > it will simply ignore the bits beyond that length. >> > >> >o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of >> > a length less than the one supported by the implementation, >> > it will consider the bits beyond the length to be unset. >> > >> > Thoughts? >> > >> > Dhruv (as a WG member) >> > >> > >> > On Thu, Feb 4, 2021 at 2:34 AM Greg Mirsky wrote: >> > >> >> Dear All, >> >> I've read the draft and support it being adopted by the PCE WG. The draft >> >> provides an elegant future-proof solution to the real problem. I have one >> >> suggestion for a future revision of this document. You've already >> >> considered backward compatibility between implementations that support the >> >> new TLV and ones that do not. I think we can envision a situation when >> >> implementations with, for example, 32 bit-long LSP Extended Flags field >> >> interwork with implementations that use 64 bit-long field. Such a >> >> situation >> >> might be far away today but it might help developers later. Also, might be >> >> helpful to explicitly note that the value in the Length field equals the >> >> length of the LSP Extended Flags field in octets (some bytes used to be >> >> only seven-bit-long). >> >> >> >> Regards, >> >> Greg >> >> >> >> On Mon, Feb 1, 2021 at 9:48 AM Dhruv Dhody wrote: >> >> >> >>> Hi WG, >> >>> >> >>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03. >> >>> >> >>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03>>> >> >>> This is a small draft that extends the flags in the LSP Objects by >> >>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing >> >>> sub-registry "LSP Object Flag Field" is almost fully assigned. >> >>> >> >>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field>>> >> >>> Should this draft be adopted by the PCE WG? Please state your reasons >
[Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11
Reviewer: Gyan Mishra Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pce-pcep-extension-for-pce-controller-?? Reviewer: Gyan Mishra Review Date: 2021-02-10 IETF LC End Date: 2021-02-08 IESG Telechat date: 2021-02-25 Summary: This document is very well written and describes a new PCEP protocol extension for using PCE as a centralized controller PCECC for provisioning using its own discrete label space for all or discrete parts static LSP ERO path. Major issues: None Minor issues: For stateful PCE how do you prevent label collisions when both the PCE is provisioning using its own label space and the routers also are using their own label space as well and have a mix of both. After the label download and sync at each router hop PCE PCC session their maybe some nodes that use the router label space and other nodes using PCE label space. It would seem more complicated to have a mix of having both PCE managed label space and non PCE managed label space and for this draft since it’s about provisioning static LSP using PCE discrete label space I think it would make more sense to have entire LSP to be provisioned using PCE label space to prevent label collisions. This caveat I think should be added to the considerations section as well. I did not see it mentioned but I think it’s also worthwhile mentioning what is the advantage of using this extension where the PCE uses its own label space. Also list the disadvantages as well so the operator had a clear picture of reasons to use this extension and maybe reasons to not use. It maybe also worthwhile to mention use cases where it makes sense to use this extension and others where it is not. In section 9 I agree it’s a good idea to have mutually authentication and encrypted sessions for all PCE PCC sessions to prevent malicious PCE using this extension. Nits/editorial comments: The abstract states the following in the last sentence which I think should better describe the goal and purpose of the draft. “ This document specifies the procedures and PCEP extensions for using the PCE as the central controller.” I would say use of PCE as a centralized controller for provisioning RSVP-TE or SR-TE static LSP explicit ERO path for all or parts of an LSP using its own discrete label space. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04
Hi Dhruv and authors Happy New Year!! I support WG adoption of this critical topic and complex problem for operators of inter domain path computation using this innovative stitching label to accomplish the task. Kind Regards Gyan On Wed, Jan 13, 2021 at 3:47 AM Belotti, Sergio (Nokia - IT/Vimercate) < sergio.belo...@nokia.com> wrote: > Hi Dhruv, all, > Thanks for extending the adoption call. > > Yes/support. > I think it is very useful document addressing a usual difficult topic of > inter-domain path computation and e2e service setup. > > Thanks > Sergio > > -Original Message- > From: Pce On Behalf Of Dhruv Dhody > Sent: Tuesday, January 12, 2021 11:38 AM > To: pce@ietf.org > Cc: pce-chairs > Subject: Re: [Pce] WG adoption poll for > draft-dugeon-pce-stateful-interdomain-04 > > Hi WG, > > The response has been limited so far. Thanks to Oliver for responding to > the comments. > > Since the adoption period coincided with holidays, we are extending the > adoption call for another week (i.e. Monday 18th Jan). We *need* to hear > from more of you before taking a call. Please respond with your support (or > not) for this work and if this I-D is a good basis to be further refined > under the control of the WG. > > Regards, > Dhruv > > On Fri, Jan 8, 2021 at 2:57 PM Dhruv Dhody wrote: > > > > Hi WG, > > > > Happy New Year! > > > > Just a reminder, the WG Adoption poll ends on Monday 11th Jan, please > > respond to the call with your support (or not), comments, etc. > > Please be more vocal on the list [1]. > > > > Thanks! > > Dhruv & Julien > > > > [1] > > https://datatracker.ietf.org/meeting/109/materials/slides-109-pce-1-in > > troduction-01 > > > Please be Vocal > > > > > > o During WG Adoption and WG LC calls, the response is less. > > > > > > o Please be vocal on the list to help us gauge the consensus better. > > > > > > o The working group mailing lists are looked at by the IESG, IAB, and > others (internal and external to IETF) to determine interest/participation > level in our standards process. > > > > > > o Please review ideas from your peers, these are community outputs of > the working group as a whole. > > > > > > > On Fri, Dec 18, 2020 at 6:22 PM Dhruv Dhody wrote: > > > > > > Hi WG, > > > > > > This email begins the WG adoption poll for > > > draft-dugeon-pce-stateful-interdomain-04. > > > > > > https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-inte > > > rdomain-04 > > > > > > 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. > > > > > > To accommodate for the holiday season, this adoption poll will end > > > on 11th Jan 2021 (Monday). > > > > > > Thanks! > > > Dhruv > > ___ > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?
I support WG adoption of this critical draft extension to support Segment Routing SR-MPLS path instantiation via SID allocation and distribution by a PCECC centralized SDN controller. This document is well written and ready for WG adoption. Thanks Gyan On Thu, Dec 10, 2020 at 8:11 AM Mahend Negi wrote: > Hi WG, > > > This draft is a useful extension which enables PCECC to leverage Segment > Routing. > > The draft clearly defines the requirements and the detailed procedures for > supporting Segment Routing by a PCECC. > > > I support the WG adoption. > > > Thanks, > > Mahendra > > > On Thu, Nov 26, 2020 at 9:05 PM wrote: > >> Hi all, >> >> PCECC extensions are progressing towards the IESG. It is time to share >> your thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09. >> Do you believe the I-D is a right foundation for a PCE WG item? Please >> use the PCE mailing list to express your comments, support or >> disagreement, including applicable rationale, especially for the latter. >> >> 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
tionality > and SDN > > > controller based ZTP functionality into a single ubiquitous server that > can do all of > > > the above and use BGP-LS to accomplish the "kitchen sink" tasks. It > does however > > > transform BGP to be an NMS tool but a "tool" and not just the original > function > > > which it was intended NLRI network reachability. > > > > Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”. > > I might argue that BGP distributing policies from installation on PEs is > an NMS protocol. > > Gyan> Agreed. One way to look at it is that as BGP primary function is > routing, however there many code points that are not necessarily routing > related , and BGP provides the ability to have each code point or SAFI or > parameters as a discrete container - to be enabled as desired, however with > that flexibility not all containers have to be used by the operator. So > the operator can custom tailor what SAFI, codepoint or parameters are > required for the implementation per design requirements and only enable > those that are necessary. So that would of course be the case for BGP-LS. > So in that case BGP can be utilized for routing or as an NMS tool extending > Netconf/Yang via BGP-LS or any other function that requires import of data > structures. And that’s Ok. > > Am I off base and please let me know as its BGP-LS is being way over > leveraged. > > > There are pros & cons to everything but I thought I would bring up to > the WG as > > > an important discussion point. > > > > Who are we to argue with real implementations? Assuming that there is a > push for implementation and deployment, then the thing to look for is > “harm”. Does this use of BGP-LS cause harm, sow confusion, risk > destabilising the network? Should it use a different code point to be > distinguishable? > > Gyan> Completely agree. I agree negative impact if any exist. See my > comments above. As BGP has the ability to compartmentalize SAFI, > codepoints and parameters into containers to be used discretely for > specific use cases tailored to the operators need. So it may feel that we > are throwing the kitchen sink at BGP and as that may not have been the > intention way back but as BGP is customizable BGP can truly be a ubiquitous > tool in the operators toolbox. > > I think the argument that “there is already another protocol for doing > this” is worth examining. But we have to be careful that it doesn’t get us > stuck, or force everyone to do something they don’t want to do. After all, > we could carry any protocol message using Netconf/YANG, but we don’t do > “RSVP-TE over Netconf”. > Gyan> Agreed Many thanks for your feedback! > > > Best, > > Adrian > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
All Another way of looking at BGP-LS is that it is an extremely powerful tool for centralized controller based architectures or hybrid architectures, and it does not bog down or impact the agility and lightweight aspects of BGP, as BGP has its overall ability to stack & pile on SAFI's and codepoint's as necessary to meet the desired design objectives. So BGP can still remain as light weight or as heavy weight as desired based on the design objective. ! BGP LS IAIA codepoints https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml So its safe to say that the use cases are pretty limitless for BGP-LS from PCE path instantiation to ZTP & Day X provisioning & configuration. I think "dump drunk" depiction of BGP-LS is really a negative perception, as BGP-LS has the native data structures primitives to build customizable TLV's to meet almost any design objective. Comments welcome. Kind Regards Gyan On Sat, Oct 10, 2020 at 3:26 PM Gyan Mishra wrote: > > Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups, > > I have noticed that after reviewing many drafts across many WGs it seems > in the industry that the lines seem to be blurred between a PCE controller, > ODL or Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day > X provisioning. > > As this is a software sitting on a server you can have a swiss army knife > server that does everything from PCE path computation to Netconf/Yang ZTP > & Day N provisioning as well as any SDN Controller ODL or Openflow > controller type functions as well. > > How this comes into play and realization of the lines being blurred is the > use of BGP-LS in building the IGP topological graph of the network which > was designed for PCEP and PCE & PCC active & passive off line path > computation for both RSVP-TE or SR-TE path instantiation. > > However now BGP-LS can also be used for other functions now such as usage > as I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use > BGP-LS to gather the elements internals within BIER using the same BGP-LS > data structures to populate with BIER specific information to graph the > BIER topology. So here we are not doing any path computations as we are > using in this use case for NMS type function to gather data for ZTP & Day > N provisioning. > > Similarly other use cases such as with TEAS TS-Transport slice and being > able to provision TS and capturing the TS Enhanced VPN RT & resource > information and leveraging BGP-LS to do the same data gathering & ZTP like > controller style provisioning. > > It does seem as though BGP-LS as its a means of "data gathering" "dump > truck" of anything with the kitchen sink included to build any type of > topological graph of literally anything under the sun. I see that is a > nice to leverage but it does in fact blur the lines of NMS Netconf/Yang > Controller based functionality and PCE path computation functionality and > SDN controller based ZTP functionality into a single ubiquitous server that > can do all of the above and use BGP-LS to accomplish the "kitchen sink" > tasks. It does however transform BGP to be an NMS tool but a "tool" and > not just the original function which it was intended NLRI network > reachability. > > Am I off base and please let me know as its BGP-LS is being way over > leveraged. There are pros & cons to everything but I thought I would bring > up to the WG as an important discussion point. > > Lots of food for thought. Welcome all comments as well as concerns > related to this topic. > > Kind Regards, > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups, I have noticed that after reviewing many drafts across many WGs it seems in the industry that the lines seem to be blurred between a PCE controller, ODL or Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X provisioning. As this is a software sitting on a server you can have a swiss army knife server that does everything from PCE path computation to Netconf/Yang ZTP & Day N provisioning as well as any SDN Controller ODL or Openflow controller type functions as well. How this comes into play and realization of the lines being blurred is the use of BGP-LS in building the IGP topological graph of the network which was designed for PCEP and PCE & PCC active & passive off line path computation for both RSVP-TE or SR-TE path instantiation. However now BGP-LS can also be used for other functions now such as usage as I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to gather the elements internals within BIER using the same BGP-LS data structures to populate with BIER specific information to graph the BIER topology. So here we are not doing any path computations as we are using in this use case for NMS type function to gather data for ZTP & Day N provisioning. Similarly other use cases such as with TEAS TS-Transport slice and being able to provision TS and capturing the TS Enhanced VPN RT & resource information and leveraging BGP-LS to do the same data gathering & ZTP like controller style provisioning. It does seem as though BGP-LS as its a means of "data gathering" "dump truck" of anything with the kitchen sink included to build any type of topological graph of literally anything under the sun. I see that is a nice to leverage but it does in fact blur the lines of NMS Netconf/Yang Controller based functionality and PCE path computation functionality and SDN controller based ZTP functionality into a single ubiquitous server that can do all of the above and use BGP-LS to accomplish the "kitchen sink" tasks. It does however transform BGP to be an NMS tool but a "tool" and not just the original function which it was intended NLRI network reachability. Am I off base and please let me know as its BGP-LS is being way over leveraged. There are pros & cons to everything but I thought I would bring up to the WG as an important discussion point. Lots of food for thought. Welcome all comments as well as concerns related to this topic. Kind Regards, <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-association-policy
ld like to use the protocol as an opaque container to associate > policies to the path. What does that policy mean and how to encode/decode > the policy parameters are expected to be done out-of-band via other > mechanisms which are better suited for policy definitions and > configurations at the PCEP speakers. Hope this helps! > > > > > > Thanks! > > > Dhruv (hat-less!) > > > > > > On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang > wrote: > > > > > > > > Hi, Authors: > > > > > > > > I Just have a quick view of this draft, and has some points wanted > > > > to be > > > > clarified: > > > > 1. This draft defines one new association type (policy association > > > > type) that follows the procedures described in RFC8697 and attached > > > > TLV? Is it right? > > > > 2. According to the text described in > > > > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new > > > > association type, the related draft should clarify its relationship > > > > between the SVEC object, if any. > > > > Should this draft to add such part? > > > > 3. For the definition of "Policy-Parameters-TLV", the "Policy > > > > Parameters" is opaque value to the PCEP peers. The draft describes > > > > the PCEP peers should know how to the encoding format of such policy > > > > in advance. But from my POV, the encoding format is the main content > > > > needs to be standardized. If such contents can't be standardized, > > > > what benefit can we get from this standardization work? What's the > reason not to standardize this? > > > > > > > > > > > > Best Regards > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > > > > > -Original Message- > > > > From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf > > > > Of Dhruv Dhody > > > > Sent: Thursday, September 17, 2020 5:42 PM > > > > To: pce@ietf.org > > > > Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs > > > > > > > > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy > > > > > > > > Hi WG, > > > > > > > > A reminder to the WG to be more vocal. I am copying this slide from > > > > the chair's WG status slide > > > > [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introd > > > > uc > > > > tion-0 > > > > 1] > > > > > > > > > Please be Vocal > > > > > > > > > > o During WG Adoption and WG LC calls, the response is less. > > > > > > > > > > o Please be vocal on the list to help us gauge the consensus better. > > > > > > > > > > o The working group mailing lists are looked at by the IESG, IAB, > > > > > and > > > > others (internal and external to IETF) to determine > > > > interest/participation level in our standards process. > > > > > > > > > > o Please review ideas from your peers, these are community outputs > > > > > of the > > > > working group as a whole. > > > > > > > > > > > > > The WG LC for the draft in question ends on Monday 21st Sept. Please > > > > respond with your explicit support (or not) for its publication. > > > > > > > > Thanks! > > > > Dhruv & Julien > > > > > > > > > > > > > > > > On Fri, Sep 4, 2020 at 10:43 AM Dhruv Dhody wrote: > > > > > > > > > > Hi WG, > > > > > > > > > > This email starts a working group last call for > > > > > draft-ietf-pce-association-policy [1]. Please indicate your > > > > > support or concern for this draft. If you are opposed to the > > > > > progression of the draft to RFC, please articulate your concern. > > > > > If you support it, please indicate that you have read the latest > > > > > version and it is ready for publication in your opinion. As > > > > > always, review comments and nits are most welcome. > > > > > > > > > > The WG LC will end on 21st September 2020. > > > > > > > > > > Thanks, > > > > > Dhruv & Julien > > > > > [1] > > > > > https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy > > > > > / > > > > > > > > ___ > > > > 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 > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling
Support publication. Gyan On Tue, Dec 17, 2019 at 1:38 PM Z.H Liu wrote: > support as contributor. > thanks > > Vic(Zhiheng) Liu > > Daniele Ceccarelli > 于2019年12月16日周一 下午10:33写道： > >> Support as well, I believe the draft is now ready for publication. >> >> Thanks, >> >> Daniele (co-author) >> >> >> >> *From:* Pce *On Behalf Of *Xufeng Liu >> *Sent:* den 12 december 2019 19:56 >> *To:* Zhangxian (Xian) >> *Cc:* pce@ietf.org >> *Subject:* Re: [Pce] WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling >> >> >> >> Support for publication. >> >> Thanks, >> >> - Xufeng >> >> >> >> On Mon, Dec 9, 2019 at 8:31 PM Zhangxian (Xian) >> wrote: >> >> The document is ready for publication.. >> >> >> >> Xian (as contributor) >> >> >> >> From: Pce on behalf of julien.meu...@orange.com < >> julien.meu...@orange.com> >> Sent: Thursday, December 5, 2019 11:47 AM >> To: pce@ietf.org >> Subject: [Pce] WG LC for draft-ietf-pce-stateful-pce-lsp-scheduling >> >> Dear PCE WG, >> >> This message starts a 2-week PCE WG Last Call for >> draft-ietf-pce-stateful-pce-lsp-scheduling-10. Please review the >> document and share your comments and/or interest using the PCE mailing >> list by Thursday December 19. >> >> 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 > -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mis...@verizon.com www.linkedin.com/in/networking-technologies-consultant ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
