Re: [Lsr] Flex Algorithms Drafts
Uma, On 02/05/18 06:06 , Uma Chunduri wrote: these are being renamed in the next update to: Flex-Algorithm - Single octet value between 128 and 255 inclusive IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that identifies IGP algorithm type used to compute paths for the Flex-Algoritm. Values are defined in "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registries Hi Peter, The above change would conflict https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml (where it is defined till 255) and how does it conflict? What we are saying is that a field contains value from the registry and we limit the values that it can use from such registry. I see no conflict. Peter cause changes to https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-25 (Which is in RFC Editor queue) https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ (In WG LC) Are we going in that direction? I still see "Flex-Algorithm" is light-weight sub-topology with constrains and still computed using one of the Algorithms as specified in https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml. Kindly avoid confusion around the terminology here, plz - Thx! -- Uma C. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
> > > these are being renamed in the next update to: > > Flex-Algorithm - Single octet value between 128 and 255 inclusive > > > IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that > identifies IGP algorithm type used to compute paths for the Flex-Algoritm. > Values are defined in "IGP Algorithm Types" registry defined under > "Interior Gateway Protocol (IGP) Parameters" IANA registries Hi Peter, The above change would conflict https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml (where it is defined till 255) and cause changes to https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-25 (Which is in RFC Editor queue) https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ (In WG LC) Are we going in that direction? I still see "Flex-Algorithm" is light-weight sub-topology with constrains and still computed using one of the Algorithms as specified in https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml. Kindly avoid confusion around the terminology here, plz - Thx! -- Uma C. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Hi Peter, Thanks for your response. See my questions below - On Tue, Apr 17, 2018 at 2:31 AM, Peter Psenak wrote: > Hi Uma, > > please see inline: > > > On 17/04/18 00:14 , Uma Chunduri wrote: > >> Dear All, >> I am neutral to combining the content of OSPF and IS-IS into a single >> draft. >> However, I have 2 questions on this draft. >> 1. >>0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type |Length | Algorithm | Metric Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Alg. Type |Priority | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sub-TLVs | >> + + >> |...| >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> */ Algorithm: Flex-Algorithm number. Value between 128 and 255/* >> */ inclusive./* >> */ Algorithm Type: Single octet identifying the algorithm type used/* >> */ to compute paths for the Flex-Algoritm. Values are defined in/* >> */ "IGP Algorithm Types" registry defined under "Interior Gateway/* >> */ Protocol (IGP) Parameters" IANA registries./* >> Why there are two fields "Algorithm" and "Algorithm Type" ? >> > > these are being renamed in the next update to: > > Flex-Algorithm - Single octet value between 128 and 255 inclusive > 1. "Algorithm " as defined in the draft - I see is nothing but a light weight sub topology (with out MT ADJs) computed using an "Alg. Type". As of now - "Algorithm" type X is using "Alg.Type" Y to compute routes? After the change you mentioned, this would become "Algorithm" type X is using "Alg.Type" Y to compute routes? IMO, Overloading of the terms cause lot of confusion (and mis-understanding) down the line. This happened already in a different context for IS-IS; ask me how I will give clear example. I followed the other thread and agree with some of the points raised by Jie w.r.t what is being defined and what is being done. > > IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that > identifies IGP algorithm type used to compute paths for the Flex-Algoritm. > Values are defined in "IGP Algorithm Types" registry defined under > "Interior Gateway Protocol (IGP) Parameters" IANA registries > What are we saving here by overloading the terminology? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Hi Uma, please see inline: On 17/04/18 00:14 , Uma Chunduri wrote: Dear All, I am neutral to combining the content of OSPF and IS-IS into a single draft. However, I have 2 questions on this draft. 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length | Algorithm | Metric Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg. Type |Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + |...| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ */ Algorithm: Flex-Algorithm number. Value between 128 and 255/* */ inclusive./* */ Algorithm Type: Single octet identifying the algorithm type used/* */ to compute paths for the Flex-Algoritm. Values are defined in/* */ "IGP Algorithm Types" registry defined under "Interior Gateway/* */ Protocol (IGP) Parameters" IANA registries./* Why there are two fields "Algorithm" and "Algorithm Type" ? these are being renamed in the next update to: Flex-Algorithm - Single octet value between 128 and 255 inclusive IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that identifies IGP algorithm type used to compute paths for the Flex-Algoritm. Values are defined in "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registries. While algorithm-type defines currently only 2 algorithms (0-SPF and 1-Strict SPF), that space can be carved out for user defined computation algorithms (I presume). If yes, then "Algorithm Type" becomes user defined flexible algorithm. 2. Also some of the sub-tlvs defined in the draft doesn't seem to belong to Router capabilities; where algorithm description is being advertised. Flexible Algorithm Exclude Admin Group Sub-TLV "The Flexible-Algorithm definition can specify 'colors' that are used by the operator to exclude links during the Flex-Algorithm path computation. FAD Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV-242. Flexible Algorithm Exclude Admin Group Sub-TLV is a sub-TLV of the FAD Sub-TLV. thanks, Peter -- Uma C. -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Thursday, April 12, 2018 2:53 AM To: Peter Psenak (ppsenak) ; lsr@ietf.org Cc: draft-hegdeppsenak-isis-sr-flex-a...@ietf.org Subject: Re: [Lsr] Flex Algorithms Drafts Hi Peter, Ok - we'll decide during whether to merge during the WG adoption call. It would be a good LSR experiment for a combined draft if there are no significant differences between the protocols that would make a combined draft unwieldy. Thanks, Acee On 4/12/18, 3:35 AM, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>> wrote: Hi Acee, On 11/04/18 22:36 , Acee Lindem (acee) wrote: > In preparation for WG adoption and IANA early code point allocation, I suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid confusion as to whether we are defining the actual metrics here. I know that in the contexts of the drafts, it is clear but the registries are going to be on their own. Additionally, while protocol TLV types should not be shared between protocols, it seems this registry could be common and placed in our "Interior Gateway Protocol (IGP) Parameters" registry. sure I can make that change. > > Finally, the OSPF version has a typo in section 8.2. The last two types should be 2 and 3. right, will fix it. > > o 0 - Reserved > > o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV > > o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV > > o 1 - Flexible Algorithm Exclude-All Group Sub-TLV > > Also, how so the authors feel about combining the drafts? I know the IS-IS version has had more discussion and wouldn't want to hold it up if there is a possibility. I don't feel strongly one way or another. I'm fine both ways. thanks, Peter > > Thanks, > Acee > ___ Lsr mailing list Lsr@ietf.org <mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Dear All, I am neutral to combining the content of OSPF and IS-IS into a single draft. However, I have 2 questions on this draft. 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length | Algorithm | Metric Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg. Type |Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + |...| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Algorithm: Flex-Algorithm number. Value between 128 and 255 inclusive. Algorithm Type: Single octet identifying the algorithm type used to compute paths for the Flex-Algoritm. Values are defined in "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registries. Why there are two fields "Algorithm" and "Algorithm Type" ? While algorithm-type defines currently only 2 algorithms (0-SPF and 1-Strict SPF), that space can be carved out for user defined computation algorithms (I presume). If yes, then "Algorithm Type" becomes user defined flexible algorithm. 2. Also some of the sub-tlvs defined in the draft doesn't seem to belong to Router capabilities; where algorithm description is being advertised. Flexible Algorithm Exclude Admin Group Sub-TLV " The Flexible-Algorithm definition can specify 'colors' that are used by the operator to exclude links during the Flex-Algorithm path computation. -- Uma C. -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Thursday, April 12, 2018 2:53 AM To: Peter Psenak (ppsenak) ; lsr@ietf.org Cc: draft-hegdeppsenak-isis-sr-flex-a...@ietf.org Subject: Re: [Lsr] Flex Algorithms Drafts Hi Peter, Ok - we'll decide during whether to merge during the WG adoption call. It would be a good LSR experiment for a combined draft if there are no significant differences between the protocols that would make a combined draft unwieldy. Thanks, Acee On 4/12/18, 3:35 AM, "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>> wrote: Hi Acee, On 11/04/18 22:36 , Acee Lindem (acee) wrote: > In preparation for WG adoption and IANA early code point allocation, I suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid confusion as to whether we are defining the actual metrics here. I know that in the contexts of the drafts, it is clear but the registries are going to be on their own. Additionally, while protocol TLV types should not be shared between protocols, it seems this registry could be common and placed in our "Interior Gateway Protocol (IGP) Parameters" registry. sure I can make that change. > > Finally, the OSPF version has a typo in section 8.2. The last two types should be 2 and 3. right, will fix it. > > o 0 - Reserved > > o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV > > o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV > > o 1 - Flexible Algorithm Exclude-All Group Sub-TLV > > Also, how so the authors feel about combining the drafts? I know the IS-IS version has had more discussion and wouldn't want to hold it up if there is a possibility. I don't feel strongly one way or another. I'm fine both ways. thanks, Peter > > Thanks, > Acee > ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
I made that point during the meeting - I see no reason at this point for 2 drafts here. Andrew From: Lsr on behalf of Toni Przygienda Date: Thursday, April 12, 2018 at 5:46 PM To: "Acee Lindem (acee)" Cc: "lsr@ietf.org" , "draft-hegdeppsenak-isis-sr-flex-a...@ietf.org" , Peter Psenak Subject: Re: [Lsr] Flex Algorithms Drafts On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) mailto:a...@cisco.com>> wrote: Hi Peter, Ok - we'll decide during whether to merge during the WG adoption call. It would be a good LSR experiment for a combined draft if there are no significant differences between the protocols that would make a combined draft unwieldy. agreed ... If the only difference is encoding really it may be far more practical to have one draft with appendix/section per protocol giving those, in a sense I wish we had a single bier-lsr draft albeit IME Peter/Les are doing an excellent job keeping things in tight lock-step ... thanks --- tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) wrote: > Hi Peter, > > Ok - we'll decide during whether to merge during the WG adoption call. It > would be a good LSR experiment for a combined draft if there are no > significant differences between the protocols that would make a combined > draft unwieldy. > > agreed ... If the only difference is encoding really it may be far more practical to have one draft with appendix/section per protocol giving those, in a sense I wish we had a single bier-lsr draft albeit IME Peter/Les are doing an excellent job keeping things in tight lock-step ... thanks --- tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Hi Peter, Ok - we'll decide during whether to merge during the WG adoption call. It would be a good LSR experiment for a combined draft if there are no significant differences between the protocols that would make a combined draft unwieldy. Thanks, Acee On 4/12/18, 3:35 AM, "Peter Psenak (ppsenak)" wrote: Hi Acee, On 11/04/18 22:36 , Acee Lindem (acee) wrote: > In preparation for WG adoption and IANA early code point allocation, I suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid confusion as to whether we are defining the actual metrics here. I know that in the contexts of the drafts, it is clear but the registries are going to be on their own. Additionally, while protocol TLV types should not be shared between protocols, it seems this registry could be common and placed in our "Interior Gateway Protocol (IGP) Parameters" registry. sure I can make that change. > > Finally, the OSPF version has a typo in section 8.2. The last two types should be 2 and 3. right, will fix it. > > o 0 - Reserved > > o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV > > o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV > > o 1 - Flexible Algorithm Exclude-All Group Sub-TLV > > Also, how so the authors feel about combining the drafts? I know the IS-IS version has had more discussion and wouldn't want to hold it up if there is a possibility. I don't feel strongly one way or another. I'm fine both ways. thanks, Peter > > Thanks, > Acee > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Hi Acee, I don't see a problem with the merge for ISIS and OSPF specs in a single document in this case. Authors are mostly identical and even though the ISIS spec was published earlier, the OSPF spec is fully in sync and leverages all those comments. A lot of the text applies to both protocols and we would just need to organize the protocol specific parts in the document. Thanks, Ketan -Original Message- From: Lsr On Behalf Of Peter Psenak (ppsenak) Sent: 12 April 2018 13:05 To: Acee Lindem (acee) ; lsr@ietf.org Cc: draft-hegdeppsenak-isis-sr-flex-a...@ietf.org Subject: Re: [Lsr] Flex Algorithms Drafts Hi Acee, On 11/04/18 22:36 , Acee Lindem (acee) wrote: > In preparation for WG adoption and IANA early code point allocation, I > suggest that we rename the “Flexible Algorithm Definition TLV Metric > Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to > avoid confusion as to whether we are defining the actual metrics here. I know > that in the contexts of the drafts, it is clear but the registries are going > to be on their own. Additionally, while protocol TLV types should not be > shared between protocols, it seems this registry could be common and placed > in our "Interior Gateway Protocol (IGP) Parameters" registry. sure I can make that change. > > Finally, the OSPF version has a typo in section 8.2. The last two types > should be 2 and 3. right, will fix it. > > o 0 - Reserved > > o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV > > o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV > > o 1 - Flexible Algorithm Exclude-All Group Sub-TLV > > Also, how so the authors feel about combining the drafts? I know the IS-IS > version has had more discussion and wouldn't want to hold it up if there is a > possibility. I don't feel strongly one way or another. I'm fine both ways. thanks, Peter > > Thanks, > Acee > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flex Algorithms Drafts
Hi Acee, On 11/04/18 22:36 , Acee Lindem (acee) wrote: In preparation for WG adoption and IANA early code point allocation, I suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid confusion as to whether we are defining the actual metrics here. I know that in the contexts of the drafts, it is clear but the registries are going to be on their own. Additionally, while protocol TLV types should not be shared between protocols, it seems this registry could be common and placed in our "Interior Gateway Protocol (IGP) Parameters" registry. sure I can make that change. Finally, the OSPF version has a typo in section 8.2. The last two types should be 2 and 3. right, will fix it. o 0 - Reserved o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV o 1 - Flexible Algorithm Exclude-All Group Sub-TLV Also, how so the authors feel about combining the drafts? I know the IS-IS version has had more discussion and wouldn't want to hold it up if there is a possibility. I don't feel strongly one way or another. I'm fine both ways. thanks, Peter Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Flex Algorithms Drafts
In preparation for WG adoption and IANA early code point allocation, I suggest that we rename the “Flexible Algorithm Definition TLV Metric Registry” to the “Flexible Algorithm Definition TLV Metric Type Registry” to avoid confusion as to whether we are defining the actual metrics here. I know that in the contexts of the drafts, it is clear but the registries are going to be on their own. Additionally, while protocol TLV types should not be shared between protocols, it seems this registry could be common and placed in our "Interior Gateway Protocol (IGP) Parameters" registry. Finally, the OSPF version has a typo in section 8.2. The last two types should be 2 and 3. o 0 - Reserved o 1 - Flexible Algorithm Exclude Admin Group Sub-TLV o 1 - Flexible Algorithm Include-Any Admin Group Sub-TLV o 1 - Flexible Algorithm Exclude-All Group Sub-TLV Also, how so the authors feel about combining the drafts? I know the IS-IS version has had more discussion and wouldn't want to hold it up if there is a possibility. I don't feel strongly one way or another. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
