Subject: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 25 Mar 2015 11:42:12 +0000

All,

The authors of draft-ietf-isis-segment-routing-extensions would 
like to expose the following proposed changes to SRGB advertisement 
which are being considered.

1. Single Vs. Multiple SRGB ranges
  Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:

  "A router not supporting multiple occurrences of the SR-Capability
   sub-TLV MUST take into consideration the first occurrence in the
   received set."

  The authors would like to remove above text so that a compliant
  implementation MUST support the receiving of multiple ranges.

2. Encoding the SR-Cap in a single LSP Fragment Vs. Single TLV
  Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:

  "The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY
   appear multiple times inside the Router Capability TLV and has
   following format [...]"

  and

  "Only the Flags in the first occurrence of the sub-TLV are to be
   taken into account"

  and

  "The originating router MUST encode ranges each into a different
   SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded
   within the same LSP fragment."

  and

  "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the
   LSP fragment is decided by the originating router and hence the
   receiving routers MUST NOT re-order the received ranges. This
   is required for avoiding label churn when for example a
   numerical lower Segment/Label Block gets added to an already
   advertised Segment/Label Block."

  Authors agreed that:
  . the encoding scheme is suboptimal and doesn't make best use of
    the TLV/LSP space (e.g.: flags field is replicated and unused).
  . we want to preserve the requirement of NOT sorting the received
    srgb ranges in order to avoid churns and downtime when a change
    is advertised (typically when the srgb is extended).

  Therefore a possible option is to restrict the advertisement of
  multiple srgb's into the SAME SR-Cap SubTLV where flags get
  defined once and srgb ranges encoded within the same (unique)
  SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).

  Now, doing this will improve the encoding and clarity of the spec
  but introduces a backward compatibility issue with current 
  version of the draft. Therefore it is important that all 
  implementors make themselves known and tell the authors how 
  difficult this change is from an implementation perspective.

  Among the authors we have 4 implementors for which the change
  seems not to be a problem but other implementations of ISIS,
  Segment Routing extension may exists and so it is necessary to
  check whether anyone has a problem with the proposed change.

Thanks.
s.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 26 Mar 2015 19:34:51 +0000

Dear Stefano and authors,

Proposed modifications (though not exact text)  are very thoughtful 
and IMO this is really good and I don't see any backward compatibility issues
(I didn't see many vendors yet advertise multiple SRGBs).

 >SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).

"SAME" ==> fragment-0 perhaps this would ensure SRGB is ALWAYS there (as this is critical for SR to even begin) 
 in the same fragment regardless on non-zero fragments have any data which are and can change, 
shrink etc.. (may be it could be too restrictive, but if this is to be considered this is the best time)?

And I have posted my comments earlier on flags to be changed to MT-ID and yet to see response and 
changes surrounding the same.

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Wednesday, March 25, 2015 6:42 AM
To: [email-masked] list
Cc: [email-masked]
Subject: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

All,

The authors of draft-ietf-isis-segment-routing-extensions would like to expose the following proposed changes to SRGB advertisement which are being considered.

  and

  and

  and

  Authors agreed that:

Thanks.
s.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 26 Mar 2015 22:36:46 +0100

hi uma,

don't you have concerns that fragment-0 might get a too crowded space ?

/hannes

On Thu, Mar 26, 2015 at 07:34:51PM +0000, Uma Chunduri wrote:
| Dear Stefano and authors,
| 
| Proposed modifications (though not exact text)  are very thoughtful 
| and IMO this is really good and I don't see any backward compatibility issues
| (I didn't see many vendors yet advertise multiple SRGBs).
| 
|  >Therefore a possible option is to restrict the advertisement of
|  >multiple srgb's into the SAME SR-Cap SubTLV where flags get
|  >defined once and srgb ranges encoded within the same (unique)
|  >SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).
| 
| "SAME" ==> fragment-0 perhaps this would ensure SRGB is ALWAYS there (as this is critical for SR to even begin) 
|  in the same fragment regardless on non-zero fragments have any data which are and can change, 
| shrink etc.. (may be it could be too restrictive, but if this is to be considered this is the best time)?
| 
| And I have posted my comments earlier on flags to be changed to MT-ID and yet to see response and 
| changes surrounding the same.
| 
| --
| Uma C.
| 
| -----Original Message-----
| From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
| Sent: Wednesday, March 25, 2015 6:42 AM
| To: [email-masked] list
| Cc: [email-masked]
| Subject: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
| 
| All,
| 
| The authors of draft-ietf-isis-segment-routing-extensions would like to expose the following proposed changes to SRGB advertisement which are being considered.
| 
| 1. Single Vs. Multiple SRGB ranges
|   Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:
| 
|   "A router not supporting multiple occurrences of the SR-Capability
|    sub-TLV MUST take into consideration the first occurrence in the
|    received set."
| 
|   The authors would like to remove above text so that a compliant
|   implementation MUST support the receiving of multiple ranges.
| 
| 2. Encoding the SR-Cap in a single LSP Fragment Vs. Single TLV
|   Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:
| 
|   "The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY
|    appear multiple times inside the Router Capability TLV and has
|    following format [...]"
| 
|   and
| 
|   "Only the Flags in the first occurrence of the sub-TLV are to be
|    taken into account"
| 
|   and
| 
|   "The originating router MUST encode ranges each into a different
|    SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded
|    within the same LSP fragment."
| 
|   and
| 
|   "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the
|    LSP fragment is decided by the originating router and hence the
|    receiving routers MUST NOT re-order the received ranges. This
|    is required for avoiding label churn when for example a
|    numerical lower Segment/Label Block gets added to an already
|    advertised Segment/Label Block."
| 
|   Authors agreed that:
|   . the encoding scheme is suboptimal and doesn't make best use of
|     the TLV/LSP space (e.g.: flags field is replicated and unused).
|   . we want to preserve the requirement of NOT sorting the received
|     srgb ranges in order to avoid churns and downtime when a change
|     is advertised (typically when the srgb is extended).
| 
|   Therefore a possible option is to restrict the advertisement of
|   multiple srgb's into the SAME SR-Cap SubTLV where flags get
|   defined once and srgb ranges encoded within the same (unique)
|   SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).
| 
|   Now, doing this will improve the encoding and clarity of the spec
|   but introduces a backward compatibility issue with current
|   version of the draft. Therefore it is important that all
|   implementors make themselves known and tell the authors how
|   difficult this change is from an implementation perspective.
| 
|   Among the authors we have 4 implementors for which the change
|   seems not to be a problem but other implementations of ISIS,
|   Segment Routing extension may exists and so it is necessary to
|   check whether anyone has a problem with the proposed change.
| 
| Thanks.
| s.
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 26 Mar 2015 22:02:10 +0000

(Hannes beat me to it! :-) )

Restricting TLVs to LSP #0 is a BAD IDEA!!

The only think special about LSP #0 is that it is required to be present in order to make use of any other LSP generated by the same system. The protocol has historically not imposed restricting TLVs to LSP #0 except in some very special cases (e.g. area addresses). This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

   Les
'

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Hannes
> Gredler
> Sent: Thursday, March 26, 2015 2:37 PM
> To: Uma Chunduri
> Cc: [email-masked] list; Stefano Previdi (sprevidi); draft-ietf-isis-segment-
> [email-masked]
> Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-
> extensions
> 
> hi uma,
> 
> | and IMO this is really good and I don't see any backward compatibility
> | issues (I didn't see many vendors yet advertise multiple SRGBs).
> |
> | >multiple srgb's into the SAME SR-Cap SubTLV where flags get  >defined
> | once and srgb ranges encoded within the same (unique)  >SR-Cap SubTLV
> | (btw, we still have room for up to 27 srgb ranges).
> |
> | "SAME" ==> fragment-0 perhaps this would ensure SRGB is ALWAYS there
> | (as this is critical for SR to even begin)  in the same fragment
> | regardless on non-zero fragments have any data which are and can change,
> | And I have posted my comments earlier on flags to be changed to MT-ID
> | and yet to see response and changes surrounding the same.
> |
> | --
> | Uma C.
> |
> | From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano
> | Previdi (sprevidi)
> | Subject: [Isis-wg] Proposed Changes in
> | draft-ietf-isis-segment-routing-extensions
> |
> | All,
> |
> | The authors of draft-ietf-isis-segment-routing-extensions would like to
> expose the following proposed changes to SRGB advertisement which are
> being considered.
> |

---

From: Chris Bowers <[email-masked]>
Date: Fri, 27 Mar 2015 13:22:07 +0000

All,

Since the changes being proposed to the ISIS SR extensions will break backwards compatibility, I would like to suggest that that working group consider taking advantage of this opportunity to improve the way that SR extensions support forwarding based on algorithms other than SPF.

Currently, in order to establish forwarding next-hops based on another algorithm, each node must be configured with an additional node-SID, each unique in the IGP domain.    The configuration and management of unique node-SIDs on a per-algorithm basis can be avoided by having each node assign a label block for each algorithm and advertise label blocks on a per-algorithm basis.  In this way, a given node only needs to have a single unique node-SID configured, while still supporting forwarding next-hops computed by different algorithms.

As far as I can tell, the main drawback of this approach is that it would break backwards compatibility with existing implementations since the current extensions do not support the association of an algorithm with a label block.  However, if we group this change together with other non-backwards compatible changes, that drawback is minimized or eliminated.

It may also make sense to take this opportunity to improve support for multi-topology routing in SR by introducing a mechanism to allow the SR-related sub-TLVs carried in the Router Capability TLV to be associated with a given MT-ID.

Chris

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Wednesday, March 25, 2015 6:42 AM
To: [email-masked] list
Cc: [email-masked]
Subject: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

All,

  and

  and

  and

  Authors agreed that:

Thanks.
s.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 27 Mar 2015 13:33:25 +0000

Hi Chris,

I fully agree to your proposal of a separate SRGB per algorithm (e.g. SPF,
MRT-Blue, MRT-Red).

Regarding your comment on Multi-topology.. Today, MT in ISIS is different
than MT in OSPF. I think OSPF already has MT built-in the OSPF protocol
extension. However there is no such need to extend that for ISIS, unless
we intend to do OSPF-like MTR.

Thanks,
-Pushpasis

On 3/27/15, 8:22 AM, "Chris Bowers" <[email-masked]> wrote:

>All,
>
>Since the changes being proposed to the ISIS SR extensions will break
>backwards compatibility, I would like to suggest that that working group
>consider taking advantage of this opportunity to improve the way that SR
>extensions support forwarding based on algorithms other than SPF.
>
>Currently, in order to establish forwarding next-hops based on another
>algorithm, each node must be configured with an additional node-SID, each
>unique in the IGP domain.    The configuration and management of unique
>node-SIDs on a per-algorithm basis can be avoided by having each node
>assign a label block for each algorithm and advertise label blocks on a
>per-algorithm basis.  In this way, a given node only needs to have a
>single unique node-SID configured, while still supporting forwarding
>next-hops computed by different algorithms.
>
>As far as I can tell, the main drawback of this approach is that it would
>break backwards compatibility with existing implementations since the
>current extensions do not support the association of an algorithm with a
>label block.  However, if we group this change together with other
>non-backwards compatible changes, that drawback is minimized or
>eliminated.
>
>It may also make sense to take this opportunity to improve support for
>multi-topology routing in SR by introducing a mechanism to allow the
>SR-related sub-TLVs carried in the Router Capability TLV to be associated
>with a given MT-ID.
>
>Chris
>
>Subject: [Isis-wg] Proposed Changes in
>draft-ietf-isis-segment-routing-extensions
>
>All,
>
>The authors of draft-ietf-isis-segment-routing-extensions would like to

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 27 Mar 2015 16:57:08 +0000

Hi Hannes,

> don't you have concerns that fragment-0 might get a too crowded space ?

Of course it could  be crowded but when I sent the mail I was just thinking on how can we ensure 
SRGB always if it is indeed provisioned on a node   in "all" situations (shrinking/HA cases for a particular node etc..). 

As we agree, unlike any other TLV/Prefix the impact of not having this in transient cases can cause complete label 
withdrawals on all receiving nodes and  have lot of impact/churn  on end-to-end LSPs using these labels.

If not fragment-0 make it mandatory to have the required stickiness (as you indicated) in the same fragment.  
Probably adding more text clarifying this would be better

Hi Les,

> This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

Perhaps "wise" but as explained above this is not about "convenience" rather avoiding potential transient loops and churn as this is a "critical" piece 
of information like area ID example you gave!

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, March 26, 2015 5:02 PM
To: Hannes Gredler; Uma Chunduri
Cc: [email-masked] list; Stefano Previdi (sprevidi); [email-masked]
Subject: RE: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

   Les
'

> Cc: [email-masked] list; Stefano Previdi (sprevidi); 
> draft-ietf-isis-segment- [email-masked]
> Subject: Re: [Isis-wg] Proposed Changes in 
> draft-ietf-isis-segment-routing- extensions
> 
> hi uma,
> 
> | and IMO this is really good and I don't see any backward 
> | compatibility issues (I didn't see many vendors yet advertise multiple SRGBs).
> |
> | >>defined
> | once and srgb ranges encoded within the same (unique)  >SR-Cap 
> | SubTLV (btw, we still have room for up to 27 srgb ranges).
> |
> | regardless on non-zero fragments have any data which are and can 
> | change,
> | And I have posted my comments earlier on flags to be changed to 
> | MT-ID and yet to see response and changes surrounding the same.
> |
> | --
> | Uma C.
> |
> | The authors of draft-ietf-isis-segment-routing-extensions would like 
> | to

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 27 Mar 2015 17:15:18 +0000

Uma -

The base protocol  specification (ISO 10589) stipulates that an implementation should refrain from moving information from one LSP to another whenever possible. This applies to ALL information advertised by IS-IS - it does not need to be repeated for any particular TLV/sub-TLV.

   Les

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Friday, March 27, 2015 9:57 AM
> To: Les Ginsberg (ginsberg); Hannes Gredler
> SRGB always if it is indeed provisioned on a node   in "all" situations
> (shrinking/HA cases for a particular node etc..).
> 
> As we agree, unlike any other TLV/Prefix the impact of not having this in
> transient cases can cause complete label withdrawals on all receiving nodes
> and  have lot of impact/churn  on end-to-end LSPs using these labels.
> 
> > This is a wise policy and we should not change it just because it seems
> "convenient" to find a particular bit of information.
> 
> Perhaps "wise" but as explained above this is not about "convenience"
> rather avoiding potential transient loops and churn as this is a "critical" piece
> The only think special about LSP #0 is that it is required to be present in order
> to make use of any other LSP generated by the same system. The protocol
> has historically not imposed restricting TLVs to LSP #0 except in some very
> special cases (e.g. area addresses). This is a wise policy and we should not
> change it just because it seems "convenient" to find a particular bit of
> information.
> 
>    Les
> '
>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 27 Mar 2015 17:28:29 +0000

Of course!

..and we know  and see how this is being followed/not followed practically in some cases in actual 
deployments (and the impact may or may not be even noticed if it is really transient and for few prefixes) .

Again my only point was this not "any" information!

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Friday, March 27, 2015 12:15 PM
To: Uma Chunduri; Hannes Gredler
Cc: [email-masked] list; Stefano Previdi (sprevidi); [email-masked]
Subject: RE: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Uma -

   Les

> Subject: RE: [Isis-wg] Proposed Changes in 
> As we agree, unlike any other TLV/Prefix the impact of not having this 
> in transient cases can cause complete label withdrawals on all 
> receiving nodes and  have lot of impact/churn  on end-to-end LSPs using these labels.
> 
> If not fragment-0 make it mandatory to have the required stickiness 
> (as you
> indicated) in the same fragment.
> rather avoiding potential transient loops and churn as this is a 
> "critical" piece of information like area ID example you gave!
> 
> --
> Uma C.
> 
> Subject: RE: [Isis-wg] Proposed Changes in 
> The only think special about LSP #0 is that it is required to be 
> present in order to make use of any other LSP generated by the same 
> system. The protocol has historically not imposed restricting TLVs to 
> LSP #0 except in some very special cases (e.g. area addresses). This 
> is a wise policy and we should not change it just because it seems 
> > | Proposed modifications (though not exact text)  are very 
> > | thoughtful and IMO this is really good and I don't see any 
> > | backward compatibility issues (I didn't see many vendors yet 
> > | advertise multiple
> SRGBs).
> > |
> > | From: Isis-wg [mailto:[email-masked]] On Behalf Of 
> > | Stefano Previdi (sprevidi)
> > | The authors of draft-ietf-isis-segment-routing-extensions would 
> > | like to
> > expose the following proposed changes to SRGB advertisement which 
> > are being considered.
> > |

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 27 Mar 2015 17:30:03 +0000

Again, absolutely no issues for me if this is understood and already factored!

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Friday, March 27, 2015 12:28 PM
To: Les Ginsberg (ginsberg); Hannes Gredler
Cc: [email-masked] list; Stefano Previdi (sprevidi); [email-masked]
Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Of course!

..and we know  and see how this is being followed/not followed practically in some cases in actual deployments (and the impact may or may not be even noticed if it is really transient and for few prefixes) .

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, March 27, 2015 12:15 PM
To: Uma Chunduri; Hannes Gredler
Cc: [email-masked] list; Stefano Previdi (sprevidi); [email-masked]
Subject: RE: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Uma -

   Les

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Sun, 29 Mar 2015 22:06:08 +0000

Hi Chris, Pushpasis,

sorry but I disagree.

The current proposal is a minor change that, will not incur ANY backward compatibility change (since nobody advertises multiple srgb's at this stage) while your proposal makes a radical change in the format of the sr-cap subtlv that would impact current deployments.

s.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 30 Mar 2015 15:26:40 +0200

hi stefano,

On Sun, Mar 29, 2015 at 10:06:08PM +0000, Stefano Previdi (sprevidi) wrote:
| Hi Chris, Pushpasis,
| 
| sorry but I disagree.
| 
| The current proposal is a minor change that, will not incur ANY backward compatibility change (since nobody advertises multiple srgb's at this stage) while your proposal makes a radical change in the format of the sr-cap subtlv that would impact current deployments.
| 

have spoken to chris offline - what he wants to do is add the algo-ID to the SRGB.

  my understanding is that this is required for resilient packet-rings in the access
  which have very constrained MPLS stacking capabilities (and R-LFA with its two labels
  blows the stacking budget and MRT single label does not) ...

The change is not as radical as it sounds -
"if an implementation does not support a non-zero algo-ID then it MUST ignore the SRGB"

and

"Every implementation MUST support the SRGBs with algo-id of zero"

/hannes

| On Mar 27, 2015, at 2:33 PM, Pushpasis Sarkar <[email-masked]> wrote:
| 
| > Hi Chris,
| > 
| > I fully agree to your proposal of a separate SRGB per algorithm (e.g. SPF,
| > MRT-Blue, MRT-Red).
| > 
| > Regarding your comment on Multi-topology.. Today, MT in ISIS is different
| > than MT in OSPF. I think OSPF already has MT built-in the OSPF protocol
| > extension. However there is no such need to extend that for ISIS, unless
| > we intend to do OSPF-like MTR.
| > 
| > Thanks,
| > -Pushpasis
| > 
| > On 3/27/15, 8:22 AM, "Chris Bowers" <[email-masked]> wrote:
| > 
| >> All,
| >> 
| >> Since the changes being proposed to the ISIS SR extensions will break
| >> backwards compatibility, I would like to suggest that that working group
| >> consider taking advantage of this opportunity to improve the way that SR
| >> extensions support forwarding based on algorithms other than SPF.
| >> 
| >> Currently, in order to establish forwarding next-hops based on another
| >> algorithm, each node must be configured with an additional node-SID, each
| >> unique in the IGP domain.    The configuration and management of unique
| >> node-SIDs on a per-algorithm basis can be avoided by having each node
| >> assign a label block for each algorithm and advertise label blocks on a
| >> per-algorithm basis.  In this way, a given node only needs to have a
| >> single unique node-SID configured, while still supporting forwarding
| >> next-hops computed by different algorithms.
| >> 
| >> As far as I can tell, the main drawback of this approach is that it would
| >> break backwards compatibility with existing implementations since the
| >> current extensions do not support the association of an algorithm with a
| >> label block.  However, if we group this change together with other
| >> non-backwards compatible changes, that drawback is minimized or
| >> eliminated.
| >> 
| >> It may also make sense to take this opportunity to improve support for
| >> multi-topology routing in SR by introducing a mechanism to allow the
| >> SR-related sub-TLVs carried in the Router Capability TLV to be associated
| >> with a given MT-ID.
| >> 
| >> Chris
| >> 
| >> -----Original Message-----
| >> From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano
| >> Previdi (sprevidi)
| >> Sent: Wednesday, March 25, 2015 6:42 AM
| >> To: [email-masked] list
| >> Cc: [email-masked]
| >> Subject: [Isis-wg] Proposed Changes in
| >> draft-ietf-isis-segment-routing-extensions
| >> 
| >> All,
| >> 
| >> The authors of draft-ietf-isis-segment-routing-extensions would like to
| >> expose the following proposed changes to SRGB advertisement which are
| >> being considered.
| >> 
| >> 1. Single Vs. Multiple SRGB ranges
| >> Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:
| >> 
| >> "A router not supporting multiple occurrences of the SR-Capability
| >>  sub-TLV MUST take into consideration the first occurrence in the
| >>  received set."
| >> 
| >> The authors would like to remove above text so that a compliant
| >> implementation MUST support the receiving of multiple ranges.
| >> 
| >> 2. Encoding the SR-Cap in a single LSP Fragment Vs. Single TLV
| >> Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:
| >> 
| >> "The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY
| >>  appear multiple times inside the Router Capability TLV and has
| >>  following format [...]"
| >> 
| >> and
| >> 
| >> "Only the Flags in the first occurrence of the sub-TLV are to be
| >>  taken into account"
| >> 
| >> and
| >> 
| >> "The originating router MUST encode ranges each into a different
| >>  SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded
| >>  within the same LSP fragment."
| >> 
| >> and
| >> 
| >> "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the
| >>  LSP fragment is decided by the originating router and hence the
| >>  receiving routers MUST NOT re-order the received ranges. This
| >>  is required for avoiding label churn when for example a
| >>  numerical lower Segment/Label Block gets added to an already
| >>  advertised Segment/Label Block."
| >> 
| >> Authors agreed that:
| >> . the encoding scheme is suboptimal and doesn't make best use of
| >>   the TLV/LSP space (e.g.: flags field is replicated and unused).
| >> . we want to preserve the requirement of NOT sorting the received
| >>   srgb ranges in order to avoid churns and downtime when a change
| >>   is advertised (typically when the srgb is extended).
| >> 
| >> Therefore a possible option is to restrict the advertisement of
| >> multiple srgb's into the SAME SR-Cap SubTLV where flags get
| >> defined once and srgb ranges encoded within the same (unique)
| >> SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).
| >> 
| >> Now, doing this will improve the encoding and clarity of the spec
| >> but introduces a backward compatibility issue with current
| >> version of the draft. Therefore it is important that all
| >> implementors make themselves known and tell the authors how
| >> difficult this change is from an implementation perspective.
| >> 
| >> Among the authors we have 4 implementors for which the change
| >> seems not to be a problem but other implementations of ISIS,
| >> Segment Routing extension may exists and so it is necessary to
| >> check whether anyone has a problem with the proposed change.
| >> 
| >> Thanks.
| >> s.
| >> 
| >> _______________________________________________
| >> Isis-wg mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/isis-wg
| >> 
| >> _______________________________________________
| >> Isis-wg mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/isis-wg
| > 
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Mar 2015 19:57:54 +0000

Hannes/Chris -

There is a rather large conceptual change being proposed here.

At present, the SRGB advertisements specify the label range(s) which a given node has reserved for use by SR - no further restrictions are defined. In most cases multiple vendors have indicated that a single SRGB range is sufficient - but the specification allows for advertisement of multiple ranges in case the label space on a given node is fragmented such that multiple ranges might be required. The suggested change Stefano has posted makes no change to this other than a very minor format change that restricts the advertisement to a single TLV for ease of use.

What the two of you are proposing is that we fundamentally change SRGB advertisements so that each range is tied to a specific SR use case. At present you are only proposing "algorithm" - but it would be just as logical to propose other contexts (for example "per topology" ranges) as well. This makes a very fundamental change in the functionality associated w an SRGB. It is no longer simply a range reserved for use by SR - it becomes a range reserved for a particular SR use case - which means multiple SRGBs would no longer be an option to address a local label allocation issue, but required to support all SR use cases. The backwards compatibility issues are MUCH LARGER and introduce a fundamental change in the attributes of an SRGB range. It will also have implications on how nodes support local label allocation.

I don't think this is necessary nor is it desirable.

   Les

> Sent: Monday, March 30, 2015 6:27 AM
> To: Stefano Previdi (sprevidi)
> Cc: [email-masked]; isis-
> [email-masked] list
> | The current proposal is a minor change that, will not incur ANY backward
> compatibility change (since nobody advertises multiple srgb's at this stage)
> while your proposal makes a radical change in the format of the sr-cap subtlv
> that would impact current deployments.
> |
> 
> The change is not as radical as it sounds - "if an implementation does not
> support a non-zero algo-ID then it MUST ignore the SRGB"
> 
> and
> 
> | > I fully agree to your proposal of a separate SRGB per algorithm
> | > (e.g. SPF, MRT-Blue, MRT-Red).
> | >
> | > Regarding your comment on Multi-topology.. Today, MT in ISIS is
> | > different than MT in OSPF. I think OSPF already has MT built-in the
> | > OSPF protocol extension. However there is no such need to extend
> | > that for ISIS, unless we intend to do OSPF-like MTR.
> | >
> | > Thanks,
> | > -Pushpasis
> | >
> | >> Since the changes being proposed to the ISIS SR extensions will
> | >> break backwards compatibility, I would like to suggest that that
> | >> working group consider taking advantage of this opportunity to
> | >> improve the way that SR extensions support forwarding based on
> algorithms other than SPF.
> | >>
> | >> Currently, in order to establish forwarding next-hops based on
> | >> another algorithm, each node must be configured with an additional
> node-SID, each
> | >> node-SIDs on a per-algorithm basis can be avoided by having each
> | >> node assign a label block for each algorithm and advertise label
> | >> blocks on a per-algorithm basis.  In this way, a given node only
> | >> needs to have a single unique node-SID configured, while still
> | >> supporting forwarding next-hops computed by different algorithms.
> | >>
> | >> As far as I can tell, the main drawback of this approach is that it
> | >> would break backwards compatibility with existing implementations
> | >> since the current extensions do not support the association of an
> | >> algorithm with a label block.  However, if we group this change
> | >> together with other non-backwards compatible changes, that drawback
> | >> is minimized or eliminated.
> | >>
> | >> It may also make sense to take this opportunity to improve support
> | >> for multi-topology routing in SR by introducing a mechanism to
> | >> allow the SR-related sub-TLVs carried in the Router Capability TLV
> | >> to be associated with a given MT-ID.
> | >>
> | >> Chris
> | >>
> | >> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> | >> Stefano Previdi (sprevidi)
> | >> The authors of draft-ietf-isis-segment-routing-extensions would
> | >> like to expose the following proposed changes to SRGB advertisement
> | >> which are being considered.
> | >>
> | >> "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the  LSP
> | >> fragment is decided by the originating router and hence the
> | >> receiving routers MUST NOT re-order the received ranges. This  is
> | >> required for avoiding label churn when for example a  numerical
> | >> lower Segment/Label Block gets added to an already  advertised
> | >> Segment/Label Block."
> | >>
> | >> multiple srgb's into the SAME SR-Cap SubTLV where flags get defined
> | >> once and srgb ranges encoded within the same (unique) SR-Cap SubTLV
> | >> (btw, we still have room for up to 27 srgb ranges).
> | >>
> | >> but introduces a backward compatibility issue with current version
> | >> of the draft. Therefore it is important that all implementors make
> | >> themselves known and tell the authors how difficult this change is
> | >> from an implementation perspective.
> | >>
> seems
> | >> not to be a problem but other implementations of ISIS, Segment
> | >> Routing extension may exists and so it is necessary to check
> | >> whether anyone has a problem with the proposed change.
> | >>
> | >> Thanks.
> | >> s.
> | >>

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 30 Mar 2015 16:58:21 -0700

I think the primary purpose of this email thread is to seek the opinion 
of the community on the very minor changes that Stefano proposed. If 
there is a feeling that other modifications are necessary or desirable, 
then a different email thread would avoid an ever growing discussion

Ahmed

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 31 Mar 2015 03:52:54 +0000

I agree and I would like to keep the changes to a minimum to ensure we provide backward compatibility with shipping code.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 31 Mar 2015 17:50:19 +0000

Hi Ahmed, Les, Stephano et al.

What we are saying that while we are making other non-backward-compatible
changes in the next version of this draft, let us consider if we can also
add some minimal more to be able address some proper kind of support for
multiple algorithms(like MRT_blue and MRT_red)Š

Does it not look sensible? I think we are making this request in the
interest of all those who also wants to do MRT with SPRING (instead of
LDP)Š I request you all to reconsider this.

Thanks
-Pushpasis

On 3/30/15, 7:58 PM, "Ahmed Bashandy" <[email-masked]> wrote:

>>algorithm, each node must be configured with an additional node-SID,
>>each unique in the IGP domain.    The configuration and management of
>>unique node-SIDs on a per-algorithm basis can be avoided by having each
>>node assign a label block for each algorithm and advertise label blocks
>>on a per-algorithm basis.  In this way, a given node only needs to have
>>a single unique node-SID configured, while still supporting forwarding
>> As far as I can tell, the main drawback of this approach is that it
>>would break backwards compatibility with existing implementations since
>>the current extensions do not support the association of an algorithm
>>with a label block.  However, if we group this change together with
>>other non-backwards compatible changes, that drawback is minimized or
>>eliminated.
>>
>>SR-related sub-TLVs carried in the Router Capability TLV to be
>>associated with a given MT-ID.
>>
>> Chris
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 31 Mar 2015 19:04:09 +0000

Pushpasis -

(Your mailer continues to insert the "bounce" alias for the WG instead of the WG address - please see if you can fix this as it means your posts won't be sent to the list. I have corrected this in my reply.)

As outlined in my post, the changes being requested are NOT minimal. They make  fundamental changes in the way SRGBs are defined/used - and have implications in the way routers implement local label allocation.

Given there is a strong desire to minimize backwards compatibility issues (publicly expressed by multiple people) it is hard for me to understand how you can suggest that now it is OK to introduce a much more disruptive change. Further, this change is NOT essential to support the use case you have in mind. 

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Pushpasis
> Sarkar
> Sent: Tuesday, March 31, 2015 10:50 AM
> To: Ahmed Bashandy (bashandy); Chris Bowers; [email-masked] list
> Cc: Stefano Previdi (sprevidi); draft-ietf-isis-segment-routing-
> [email-masked]
> What we are saying that while we are making other non-backward-
> compatible changes in the next version of this draft, let us consider if we can
> also add some minimal more to be able address some proper kind of support
> for multiple algorithms(like MRT_blue and MRT_red)Š
> 
> Does it not look sensible? I think we are making this request in the interest of
> all those who also wants to do MRT with SPRING (instead of LDP)Š I request
> you all to reconsider this.
> 
> Thanks
> -Pushpasis
> 
> >>backwards compatibility, I would like to suggest that that working
> >>group consider taking advantage of this opportunity to improve the way
> >>that SR extensions support forwarding based on algorithms other than
> SPF.
> >>
> >> Currently, in order to establish forwarding next-hops based on
> >>another algorithm, each node must be configured with an additional node-
> SID,
> >>unique node-SIDs on a per-algorithm basis can be avoided by having
> >>each node assign a label block for each algorithm and advertise label
> >>blocks on a per-algorithm basis.  In this way, a given node only needs
> >>to have a single unique node-SID configured, while still supporting
> >>forwarding next-hops computed by different algorithms.
> >>
> >>would break backwards compatibility with existing implementations
> >>since the current extensions do not support the association of an
> >>algorithm with a label block.  However, if we group this change
> >>together with other non-backwards compatible changes, that drawback is
> >>minimized or eliminated.
> >>
> >> It may also make sense to take this opportunity to improve support
> >>for multi-topology routing in SR by introducing a mechanism to allow
> >>the SR-related sub-TLVs carried in the Router Capability TLV to be
> >> The authors of draft-ietf-isis-segment-routing-extensions would like
> >>to expose the following proposed changes to SRGB advertisement which
> >>are being considered.
> >>

---

From: Chris Bowers <[email-masked]>
Date: Tue, 31 Mar 2015 19:06:54 +0000

Les,

Here is a practical example of the issue with using per-algorithm node-SIDs.  Suppose an operator has a network with 100 nodes (R0 -R99).  They assign unique Node-SIDs 0-99 to those nodes for algorithm=0, in order to accomplish shortest path routing based on IGP metric with SR labels.  Each node will need to advertise a label block of size=100.  

Assume that at some future point in time, the IETF defines algorithm=1 to mean shortest path routing based on latency, and vendors implement this.  Suppose that the operator wants to use latency-based SPF routes for some traffic and metric-based SPF routes for other traffic.   The operator will need to define a new set of unique Node-SIDs for algorithm=1.  A reasonable choice would be to assign Node-SID values of 100-199 to R0-R99 for algorithm=1.  Each node will now need to advertise a label block of size=200.  So far the need for per-algorithm node-SIDs is an annoyance, but not too difficult to deal with.  

Now assume that the operator needs to add 10 new nodes to the SR domain, specifically nodes R100-R109.  Each node needs to advertise a label block of size=220.   The main issue is deciding how to assign per-algorithm node-SIDs for the 10 new nodes?  One option is to redo the node-SID numbering scheme so that R0-R109 have node-SIDs 0-109 for algorithm=0 and node-SIDs 110-229 for algorithm=1.  However, this require renumbering existing nodes.  The other option is to avoid renumbering of nodes by assigning nodes R100-R109 node-SIDs 200-209 for algorithm=0 and node-SIDs 210-219 for algorithm=1. Each of these options has drawbacks.  The first requires renumbering existing nodes, while the second is difficult to maintain since there is no obvious relationship between the node-SIDs for different algorithms.

Instead, the use of per-algorithm label-blocks avoids this problem completely.  When the SR domain is initially deployed, R0-R99 can be assigned node-SIDs 0-99 as one would expect.  When support for algorithm=1 gets added,  the operator does not need to assign and configure any new node-SIDs.  Instead, the routers automate the process by advertising different label blocks for each algorithm.  When another 10 nodes get added to the SR domain, R100-R109 get assigned node-SIDs 100-109 as one would expect.  And the router advertises a label block of size=110 for each algorithm, as one would expect.  Adding new nodes in the presence of multiple algorithms is simplified significantly with the use of per-algorithm label blocks.

As you point out, the same logic applies to multiple topologies, so it would make sense to advertise per-topology label blocks.

There are other numbering schemes for per-algorithm node-SIDs that one can consider, but as far as I can tell, they run into problems when trying to add more nodes or more algorithms.  One could also lessen the impact of this somewhat by anticipating growth in each of the dimensions (number of nodes, number of algorithms, and number of topologies) and pre-assigning node-SIDs based on anticipated maximum values in each dimension, but this can result in advertising label blocks that are potentially much larger than actually needed.

Chris

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, March 30, 2015 2:58 PM
To: Hannes Gredler; Stefano Previdi (sprevidi)
Cc: [email-masked] list; [email-masked]
Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Hannes/Chris -

   Les

> | The current proposal is a minor change that, will not incur ANY 
> | backward
> compatibility change (since nobody advertises multiple srgb's at this 
> stage) while your proposal makes a radical change in the format of the 
> sr-cap subtlv that would impact current deployments.
> |
> 
> The change is not as radical as it sounds - "if an implementation does 
> not support a non-zero algo-ID then it MUST ignore the SRGB"
> 
> and
> 
> | > different than MT in OSPF. I think OSPF already has MT built-in 
> | > the OSPF protocol extension. However there is no such need to 
> | > extend that for ISIS, unless we intend to do OSPF-like MTR.
> | >
> | > Thanks,
> | > -Pushpasis
> | >
> | >> another algorithm, each node must be configured with an 
> | >> additional
> node-SID, each
> | >> As far as I can tell, the main drawback of this approach is that 
> | >> it would break backwards compatibility with existing 
> | >> implementations since the current extensions do not support the 
> | >> association of an algorithm with a label block.  However, if we 
> | >> group this change together with other non-backwards compatible 
> | >> changes, that drawback is minimized or eliminated.
> | >>
> | >> It may also make sense to take this opportunity to improve 
> | >> support for multi-topology routing in SR by introducing a 
> | >> mechanism to allow the SR-related sub-TLVs carried in the Router 
> | >> Capability TLV to be associated with a given MT-ID.
> | >>
> | >> Chris
> | >>
> | >> like to expose the following proposed changes to SRGB 
> | >> advertisement which are being considered.
> | >>
> | >> 1. Single Vs. Multiple SRGB ranges Currently, section 3.1.  
> | >> SR-Capabilities Sub-TLV defines that:
> | >>
> | >> "A router not supporting multiple occurrences of the 
> | >> SR-Capability sub-TLV MUST take into consideration the first 
> | >> occurrence in the received set."
> | >>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 31 Mar 2015 19:22:18 +0000

Chris -

I understood what you intended from your original post. The extension you are suggesting makes it "more convenient" to configure SIDs for multiple topologies since you can use the same index in multiple SRGBs. But it is possible to support your use case w a single SRGB.

Now, could you please acknowledge the points I made?

1)You are fundamentally changing the context associated w an SRGB

2)You are now REQUIRING the use of multiple SRGBs to support the full set of SR use cases (currently one SRGB is sufficient)

3)You are introducing new requirements on how a given router allocates local labels

4)The backwards compatibility issues w existing deployments are much greater w your proposal 

Given the concern about existing deployments #4 alone seems sufficient to not go in the direction you suggest. But the other three points add considerable additional weight to the argument against your proposal.

   Les

> From: Chris Bowers [mailto:[email-masked]]
> Sent: Tuesday, March 31, 2015 12:07 PM
> To: Les Ginsberg (ginsberg); Hannes Gredler; Stefano Previdi (sprevidi)
> Here is a practical example of the issue with using per-algorithm node-SIDs.
> Suppose an operator has a network with 100 nodes (R0 -R99).  They assign
> unique Node-SIDs 0-99 to those nodes for algorithm=0, in order to
> accomplish shortest path routing based on IGP metric with SR labels.  Each
> node will need to advertise a label block of size=100.
> 
> Assume that at some future point in time, the IETF defines algorithm=1 to
> mean shortest path routing based on latency, and vendors implement this.
> Suppose that the operator wants to use latency-based SPF routes for some
> traffic and metric-based SPF routes for other traffic.   The operator will need
> to define a new set of unique Node-SIDs for algorithm=1.  A reasonable
> choice would be to assign Node-SID values of 100-199 to R0-R99 for
> algorithm=1.  Each node will now need to advertise a label block of size=200.
> So far the need for per-algorithm node-SIDs is an annoyance, but not too
> difficult to deal with.
> 
> Now assume that the operator needs to add 10 new nodes to the SR domain,
> specifically nodes R100-R109.  Each node needs to advertise a label block of
> size=220.   The main issue is deciding how to assign per-algorithm node-SIDs
> for the 10 new nodes?  One option is to redo the node-SID numbering
> scheme so that R0-R109 have node-SIDs 0-109 for algorithm=0 and node-SIDs
> 110-229 for algorithm=1.  However, this require renumbering existing nodes.
> The other option is to avoid renumbering of nodes by assigning nodes R100-
> R109 node-SIDs 200-209 for algorithm=0 and node-SIDs 210-219 for
> algorithm=1. Each of these options has drawbacks.  The first requires
> renumbering existing nodes, while the second is difficult to maintain since
> there is no obvious relationship between the node-SIDs for different
> algorithms.
> 
> Instead, the use of per-algorithm label-blocks avoids this problem
> completely.  When the SR domain is initially deployed, R0-R99 can be
> assigned node-SIDs 0-99 as one would expect.  When support for
> algorithm=1 gets added,  the operator does not need to assign and configure
> any new node-SIDs.  Instead, the routers automate the process by
> advertising different label blocks for each algorithm.  When another 10 nodes
> get added to the SR domain, R100-R109 get assigned node-SIDs 100-109 as
> one would expect.  And the router advertises a label block of size=110 for
> each algorithm, as one would expect.  Adding new nodes in the presence of
> multiple algorithms is simplified significantly with the use of per-algorithm
> label blocks.
> 
> As you point out, the same logic applies to multiple topologies, so it would
> make sense to advertise per-topology label blocks.
> 
> There are other numbering schemes for per-algorithm node-SIDs that one
> can consider, but as far as I can tell, they run into problems when trying to
> add more nodes or more algorithms.  One could also lessen the impact of this
> somewhat by anticipating growth in each of the dimensions (number of
> nodes, number of algorithms, and number of topologies) and pre-assigning
> node-SIDs based on anticipated maximum values in each dimension, but this
> can result in advertising label blocks that are potentially much larger than
> actually needed.
> 
> Chris
> 
> At present, the SRGB advertisements specify the label range(s) which a given
> node has reserved for use by SR - no further restrictions are defined. In most
> cases multiple vendors have indicated that a single SRGB range is sufficient -
> but the specification allows for advertisement of multiple ranges in case the
> label space on a given node is fragmented such that multiple ranges might be
> required. The suggested change Stefano has posted makes no change to this
> other than a very minor format change that restricts the advertisement to a
> single TLV for ease of use.
> 
> What the two of you are proposing is that we fundamentally change SRGB
> advertisements so that each range is tied to a specific SR use case. At present
> you are only proposing "algorithm" - but it would be just as logical to propose
> other contexts (for example "per topology" ranges) as well. This makes a
> very fundamental change in the functionality associated w an SRGB. It is no
> longer simply a range reserved for use by SR - it becomes a range reserved
> for a particular SR use case - which means multiple SRGBs would no longer be
> an option to address a local label allocation issue, but required to support all
> SR use cases. The backwards compatibility issues are MUCH LARGER and
> introduce a fundamental change in the attributes of an SRGB range. It will
> also have implications on how nodes support local label allocation.
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 31 Mar 2015 19:36:48 +0000

Hi Les,

Thanks for correcting the bounce issue.. Hope it does not go the bounce
list anymore... 

More comments inline..

On 3/31/15, 3:04 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>Pushpasis -
>
>(Your mailer continues to insert the "bounce" alias for the WG instead of
>the WG address - please see if you can fix this as it means your posts
>won't be sent to the list. I have corrected this in my reply.)
>
>As outlined in my post, the changes being requested are NOT minimal. They
>make  fundamental changes in the way SRGBs are defined/used - and have
>implications in the way routers implement local label allocation.
>
>Given there is a strong desire to minimize backwards compatibility issues
>(publicly expressed by multiple people) it is hard for me to understand
>how you can suggest that now it is OK to introduce a much more disruptive
>change. 
[Pushpasis] All we are asking is an extra ALGO field in the
SR-Cap-SubTLV.. Existing implementations (that do SPF only) just adds a
Algo field with value '0'... Is it so hard to implement? I don't think I
sound so ridiculous... :) If people have to make some code changes to
accommodate the changes being proposed originally in this thread.. Might
as well add few lines for this Algo field...

>Further, this change is NOT essential to support the use case you have in
>mind.
[Pushpasis] I agree to disagree.. This makes perfect sense the way forward
to do MRT and other kinds of algorithms...

Thanks and Regards,
-Pushpasis
 
>>interest of

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 31 Mar 2015 21:05:58 +0000

Pushpasis, Chris,

please, try to remain in-scope of my original email. See below.

> as well add few lines for this Algo field...

adding a field into an existing TLV makes its format backward incompatible.
Not a big deal if nobody did implement it but as a matter of fact, there are MULTIPLE implementations that are being deployed.

Please read carefully the original email I sent. The proposed changes do not cause any backward compatibility issue due to the current stage of implementations (i.e.: nobody advertises multiple srgb's). Therefore the proposed changes are minor and do not interfere AT ALL with current deployments.

What you propose is radically different and I'd suggest NOT to diverge from the original intend of my email. If you have additional requirements (i.e.: MRT, MT, MI, whatever) I'd suggest you to document them into a separate draft and perhaps define a new set of TLVs or subTLVs that future revisions may incorporate.

What must be considered is that we have on going deployments with shipped code and we won't introduce backward incompatible IMPLEMENTATION changes. Once again, the change that is proposed does NOT affect any implementation.

s.

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 31 Mar 2015 16:09:49 -0700

Hi Pushpasis

*In this email thread*, I am not discussing the sensibility, 
appropriateness, size, impact,..., etc of the other suggestions. I want 
to reach conclusion on the matter under discussion.

If someone feels that there is a need for other modifications 
(irrespective of the his/her assessment of the impact of these other 
modifications), then a separate email thread is more appropriate to be 
able to close on the modifications proposed in this email thread

Ahmed