Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Hi, As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD means that the node is defacto ELC (so advertising ELC separately is not necessary): " The Entropy Readable Label Depth (ERLD) is defined as the number of labels a router can both: a. Read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack). b. Use in its load-balancing function. The ERLD means that the router will perform load-balancing using the EL label if the EL is placed within the ERLD first labels. " " To advertise an ERLD value, a SPRING router: o MUST be entropy label capable and, as a consequence, MUST apply the dataplane procedures defined in [RFC6790]. o MUST be able to read an ELI/EL which is located within its ERLD value. o MUST take into account this EL in its load-balancing function. " Brgds, -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Wednesday, June 13, 2018 11:10 To: Ketan Talaulikar (ketant); i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS) It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are signaled for ISIS, OSPF and BGP-LS. If the WG's can manage to agree upon a decision (option1/2/3 or 4), then next, have a look into how to encode the TLV so that we have a clean technological solution space. G/ -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Wednesday, June 13, 2018 10:45 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, In that case, I concur with you that option (2) is better than the others. My only difference in opinion is that ERLD not have its own separate TLV but instead get advertised as a new MSD sub-type - it is just a different encoding. Thanks, Ketan -Original Message- From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: 13 June 2018 13:55 To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic motivation. The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is available, then ELC can be implicitly assumed. No pragmatic reason to signal separately, as it just make things more complex then should be. >From a holistic perspective having something similar, yet different, in both >IGP and BGP-LS encoding seems to make little sense and only bring confusion >(router/controller implementers and network operators). The ways to address this in IGP and BGP-LS going forward: 1) do nothing and leave all as it is (it has potential to create massive confusion) 2) only signal ERLD TLV in IGP and BGP 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of ELC TLV compared to option (2)) 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more complex as option (2)) I believe that option (2) is the best option: * it bring the needed readable label depth value to operators * most simple solution for implementers (routers and controller) * easy to understand with no confusion * is compliant with draft-ietf-mpls-spring-entropy-label-10 G/ -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Wednesday, June 13, 2018 08:05 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, The difference in IGP signalling seems to be because the ELC is a capability which is advertised differently than ERLD which is a limit. Are you saying that ELC does not have value by itself without the ERLD? IMHO it makes sense to retain ELC as capability of the router (as specified in the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. This way we have the flexibility of signalling ERLD both per node and per ingress link/LC level. Thanks, Ketan -Original Message- From: Idr On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: 12 June 2018 19:28 To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS) In LSR WG the following drafts document the signaling of ELC and RLD: * draft-ietf-ospf-mpls-elc * draft-ietf-isis-mpls-elc When exporting this information using BGP-LS encoding to a controller, there is need for BGP-LS extension by means of new TLVs. BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is signaling individually ELC and RLD I was working upon the IANA section, and discovered some inconsistency that should be addressed: * Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon
Re: [Lsr] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Gunter, I have nothing to add to Les' comments, 100% agree. Cheers, Jeff On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)" wrote: Gunter - I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD. This is the unified framework that the MSD advertisement has been designed to support. The following documents provide a unified definition of this mechanism: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ (The last one needs a refresh.) If we can update the related ERLD documents to align I think we will have an excellent solution. (Note: in the case of https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ perhaps that can be combined with https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ - but I leave that to the respective authors to work out.) Les > -Original Message- > From: Lsr On Behalf Of Van De Velde, Gunter (Nokia > - BE/Antwerp) > Sent: Wednesday, June 13, 2018 2:10 AM > To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS) > > It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are > signaled for ISIS, OSPF and BGP-LS. > > If the WG's can manage to agree upon a decision (option1/2/3 or 4), then > next, have a look into how to encode the TLV so that we have a clean > technological solution space. > > G/ > > -Original Message- > From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > Sent: Wednesday, June 13, 2018 10:45 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Hi Gunter, > > In that case, I concur with you that option (2) is better than the others. My > only difference in opinion is that ERLD not have its own separate TLV but > instead get advertised as a new MSD sub-type - it is just a different encoding. > > Thanks, > Ketan > > -Original Message- > From: Van De Velde, Gunter (Nokia - BE/Antwerp) > > Sent: 13 June 2018 13:55 > To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Indeed, the debate that made BGP-LS to go down the ERLD path is of > pragmatic motivation. > > The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV > is available, then ELC can be implicitly assumed. No pragmatic reason to signal > separately, as it just make things more complex then should be. > > >From a holistic perspective having something similar, yet different, in both > IGP and BGP-LS encoding seems to make little sense and only bring > confusion (router/controller implementers and network operators). > > The ways to address this in IGP and BGP-LS going forward: > 1) do nothing and leave all as it is (it has potential to create massive > confusion) > 2) only signal ERLD TLV in IGP and BGP > 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of > ELC TLV compared to option (2)) > 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more > complex as option (2)) > > I believe that option (2) is the best option: > * it bring the needed readable label depth value to operators > * most simple solution for implementers (routers and controller) > * easy to understand with no confusion > * is compliant with draft-ietf-mpls-spring-entropy-label-10 > > G/ > > -Original Message- > From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > Sent: Wednesday, June 13, 2018 08:05 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Hi Gunter, > > The difference in IGP signalling seems to be because the ELC is a capability > which is advertised differently than ERLD which is a limit. Are you saying that > ELC does not have value by itself without the ERLD? > > IMHO it makes sense to retain ELC as capability of the router (as specified in > the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. > This way we have the flexibility of signalling ERLD both per node and per > ingress link/LC level. > > Thanks, > Ketan > >
Re: [Lsr] IPR Poll draft-ietf-isis-segment-routing-msd.
Chris, I'm not aware of any IPR outside of that already disclosed. Thanks, Jeff Cheers, Jeff On 6/13/18, 06:37, "Christian Hopps" wrote: [Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!] Authors, The original WGLC requested the authors indicate if they were aware of any additional IPR. This seems to have gotten lost in a bunch of comments that followed. Can each author reply to this email (and the list) indicating if they are aware of any *new* IPR on this document. Currently declared related IPR: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-segment-routing-msd Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Gunter - I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD. This is the unified framework that the MSD advertisement has been designed to support. The following documents provide a unified definition of this mechanism: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ (The last one needs a refresh.) If we can update the related ERLD documents to align I think we will have an excellent solution. (Note: in the case of https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ perhaps that can be combined with https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ - but I leave that to the respective authors to work out.) Les > -Original Message- > From: Lsr On Behalf Of Van De Velde, Gunter (Nokia > - BE/Antwerp) > Sent: Wednesday, June 13, 2018 2:10 AM > To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS) > > It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are > signaled for ISIS, OSPF and BGP-LS. > > If the WG's can manage to agree upon a decision (option1/2/3 or 4), then > next, have a look into how to encode the TLV so that we have a clean > technological solution space. > > G/ > > -Original Message- > From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > Sent: Wednesday, June 13, 2018 10:45 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Hi Gunter, > > In that case, I concur with you that option (2) is better than the others. My > only difference in opinion is that ERLD not have its own separate TLV but > instead get advertised as a new MSD sub-type - it is just a different > encoding. > > Thanks, > Ketan > > -Original Message- > From: Van De Velde, Gunter (Nokia - BE/Antwerp) > > Sent: 13 June 2018 13:55 > To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Indeed, the debate that made BGP-LS to go down the ERLD path is of > pragmatic motivation. > > The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV > is available, then ELC can be implicitly assumed. No pragmatic reason to > signal > separately, as it just make things more complex then should be. > > >From a holistic perspective having something similar, yet different, in both > IGP and BGP-LS encoding seems to make little sense and only bring > confusion (router/controller implementers and network operators). > > The ways to address this in IGP and BGP-LS going forward: > 1) do nothing and leave all as it is (it has potential to create massive > confusion) > 2) only signal ERLD TLV in IGP and BGP > 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling > of > ELC TLV compared to option (2)) > 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more > complex as option (2)) > > I believe that option (2) is the best option: > * it bring the needed readable label depth value to operators > * most simple solution for implementers (routers and controller) > * easy to understand with no confusion > * is compliant with draft-ietf-mpls-spring-entropy-label-10 > > G/ > > -Original Message- > From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > Sent: Wednesday, June 13, 2018 08:05 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; i...@ietf.org; lsr@ietf.org; > spr...@ietf.org > Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) > > Hi Gunter, > > The difference in IGP signalling seems to be because the ELC is a capability > which is advertised differently than ERLD which is a limit. Are you saying > that > ELC does not have value by itself without the ERLD? > > IMHO it makes sense to retain ELC as capability of the router (as specified in > the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. > This way we have the flexibility of signalling ERLD both per node and per > ingress link/LC level. > > Thanks, > Ketan > > -Original Message- > From: Idr On Behalf Of Van De Velde, Gunter (Nokia > - BE/Antwerp) > Sent: 12 June 2018 19:28 > To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org > Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS) > > In LSR WG the following drafts document the signaling of ELC and RLD: > * draft-ietf-ospf-mpls-elc > * draft-ietf-isis-mpls-elc > > When exporting this information using BGP-LS encoding to a controller, there > is need for BGP-LS extension by means of new TLVs. > > BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is > signaling
[Lsr] IPR Poll draft-ietf-isis-segment-routing-msd.
[Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!] Authors, The original WGLC requested the authors indicate if they were aware of any additional IPR. This seems to have gotten lost in a bunch of comments that followed. Can each author reply to this email (and the list) indicating if they are aware of any *new* IPR on this document. Currently declared related IPR: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-segment-routing-msd Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IPR Poll [Re: WG Last Call for draft-ietf-isis-segment-routing-extensions-16]
Authors, The original WGLC requested the authors indicate if they were aware of any additional IPR. This seems to have gotten lost in a bunch of comments that followed. I failed to ask again during this second WGLC. So... Can each author reply to this email (and the list) indicating if they are aware of any *new* IPR on this document. Currently declared related IPR: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-segment-routing-msd Thanks, Chris. Christian Hopps writes: Hi Folks, We are starting a new 2 week WG last call on https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ as there have (*) been some changes to the document since our last WG last call last year. Here's the diff. https://www.ietf.org/rfcdiff?url1=draft-ietf-isis-segment-routing-extensions-12=draft-ietf-isis-segment-routing-extensions-16 Will end Monday May 7th. Thanks, Chris. (*) contrary to what you may have heard from folks at the mic in London. :) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Hi Gunter, In that case, I concur with you that option (2) is better than the others. My only difference in opinion is that ERLD not have its own separate TLV but instead get advertised as a new MSD sub-type - it is just a different encoding. Thanks, Ketan -Original Message- From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: 13 June 2018 13:55 To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic motivation. The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is available, then ELC can be implicitly assumed. No pragmatic reason to signal separately, as it just make things more complex then should be. >From a holistic perspective having something similar, yet different, in both >IGP and BGP-LS encoding seems to make little sense and only bring confusion >(router/controller implementers and network operators). The ways to address this in IGP and BGP-LS going forward: 1) do nothing and leave all as it is (it has potential to create massive confusion) 2) only signal ERLD TLV in IGP and BGP 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of ELC TLV compared to option (2)) 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more complex as option (2)) I believe that option (2) is the best option: * it bring the needed readable label depth value to operators * most simple solution for implementers (routers and controller) * easy to understand with no confusion * is compliant with draft-ietf-mpls-spring-entropy-label-10 G/ -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Wednesday, June 13, 2018 08:05 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, The difference in IGP signalling seems to be because the ELC is a capability which is advertised differently than ERLD which is a limit. Are you saying that ELC does not have value by itself without the ERLD? IMHO it makes sense to retain ELC as capability of the router (as specified in the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. This way we have the flexibility of signalling ERLD both per node and per ingress link/LC level. Thanks, Ketan -Original Message- From: Idr On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: 12 June 2018 19:28 To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS) In LSR WG the following drafts document the signaling of ELC and RLD: * draft-ietf-ospf-mpls-elc * draft-ietf-isis-mpls-elc When exporting this information using BGP-LS encoding to a controller, there is need for BGP-LS extension by means of new TLVs. BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is signaling individually ELC and RLD I was working upon the IANA section, and discovered some inconsistency that should be addressed: * Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10) * What are the plans to request IANA code points for these drafts? * (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK ERLD is not of any value at all, is that a correct assumption?) G/ -Original Message- From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Tuesday, June 12, 2018 15:25 To: i-d-annou...@ietf.org Cc: i...@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signalling ERLD using BGP-LS Authors : Gunter Van de Velde Wim Henderickx Matthew Bocci Keyur Patel Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt Pages : 6 Date: 2018-06-12 Abstract: This document defines the attribute encoding to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node to a centralised controller (PCE/SDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02 Please note that it may take a couple of minutes
Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic motivation. The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is available, then ELC can be implicitly assumed. No pragmatic reason to signal separately, as it just make things more complex then should be. >From a holistic perspective having something similar, yet different, in both >IGP and BGP-LS encoding seems to make little sense and only bring confusion (router/controller implementers and network operators). The ways to address this in IGP and BGP-LS going forward: 1) do nothing and leave all as it is (it has potential to create massive confusion) 2) only signal ERLD TLV in IGP and BGP 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of ELC TLV compared to option (2)) 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more complex as option (2)) I believe that option (2) is the best option: * it bring the needed readable label depth value to operators * most simple solution for implementers (routers and controller) * easy to understand with no confusion * is compliant with draft-ietf-mpls-spring-entropy-label-10 G/ -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Wednesday, June 13, 2018 08:05 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, The difference in IGP signalling seems to be because the ELC is a capability which is advertised differently than ERLD which is a limit. Are you saying that ELC does not have value by itself without the ERLD? IMHO it makes sense to retain ELC as capability of the router (as specified in the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. This way we have the flexibility of signalling ERLD both per node and per ingress link/LC level. Thanks, Ketan -Original Message- From: Idr On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: 12 June 2018 19:28 To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS) In LSR WG the following drafts document the signaling of ELC and RLD: * draft-ietf-ospf-mpls-elc * draft-ietf-isis-mpls-elc When exporting this information using BGP-LS encoding to a controller, there is need for BGP-LS extension by means of new TLVs. BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is signaling individually ELC and RLD I was working upon the IANA section, and discovered some inconsistency that should be addressed: * Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10) * What are the plans to request IANA code points for these drafts? * (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK ERLD is not of any value at all, is that a correct assumption?) G/ -Original Message- From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Tuesday, June 12, 2018 15:25 To: i-d-annou...@ietf.org Cc: i...@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signalling ERLD using BGP-LS Authors : Gunter Van de Velde Wim Henderickx Matthew Bocci Keyur Patel Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt Pages : 6 Date: 2018-06-12 Abstract: This document defines the attribute encoding to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node to a centralised controller (PCE/SDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr ___ Lsr
