Subject: [Lsr] Flex Algorithms Drafts

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Apr 2018 20:36:41 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Apr 2018 09:35:29 +0200

Hi Acee,

> 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 Metri…

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.
> 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 o…

I'm fine both ways.

thanks,
Peter

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Apr 2018 09:48:37 +0000

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 <[email-masked]> On Behalf Of Peter Psenak (ppsenak)
Sent: 12 April 2018 13:05
To: Acee Lindem (acee) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Flex Algorithms Drafts

Hi Acee,

right, will fix it.

I'm fine both ways.

thanks,
Peter

> Acee

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 12 Apr 2018 09:52:42 +0000

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)" <[email-masked]> wrote:

    Hi Acee,

    
    
    right, will fix it.
    
    I'm fine both ways.
    
    thanks,
    Peter

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 12 Apr 2018 08:44:49 -0700

On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) <[email-masked]> 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

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 12 Apr 2018 16:42:22 +0000

I made that point during the meeting -  I see no reason at this point for 2 drafts here.

Andrew

From: Lsr <[email-masked]> on behalf of Toni Przygienda <[email-masked]>
Date: Thursday, April 12, 2018 at 5:46 PM
To: "Acee Lindem (acee)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Peter Psenak <[email-masked]>
Subject: Re: [Lsr] Flex Algorithms Drafts

On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Peter,

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

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 16 Apr 2018 22:14:47 +0000

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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 12, 2018 2:53 AM
To: Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Flex Algorithms Drafts

Hi Peter,

Thanks,
Acee

On 4/12/18, 3:35 AM, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi Acee,

    right, will fix it.

    I'm fine both ways.

    thanks,
    Peter

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Tue, 17 Apr 2018 11:31:11 +0200

Hi Uma,

please see inline:

On 17/04/18 00:14 , Uma Chunduri wrote:
> */       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./*

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.
>     "The Flexible-Algorithm definition can specify 'colors' that are used

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

> 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
>      > 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.
>      > 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
>      >
> [email-masked] <mailto:[email-masked]>