Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Ron Bonica]

Me too.



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, April 14, 2022 10:55 AM
To: Robert Raszuk ; John E Drake 
Cc: Peter Psenak (ppsenak) ; Ketan Talaulikar 
; draft-ietf-lsr-ip-flexa...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[External Email. Be cautious of content]

Speaking as document shepherd and WG member:

I don't have a problem with "MPLS SR and SRv6 data planes" but wouldn't be 
opposed to "MPLS SR and SRv6 logical data planes".

Thanks,
Acee

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, April 14, 2022 at 9:51 AM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>, 
Ketan Talaulikar mailto:ketant.i...@gmail.com>>, Acee 
Lindem mailto:a...@cisco.com>>, 
"draft-ietf-lsr-ip-flexa...@ietf.org"
 
mailto:draft-ietf-lsr-ip-flexa...@ietf.org>>,
 "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John,

In the IETF context I have always associated 'data plane' with packet 
forwarding,

No one disputes that.

But the fact that various sub-data-planes are built on top of base physical 
data planes needs to be clearly distinguished.

Kind regards,
R.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call IPR poll for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Ron Bonica]

Folks,

I am not aware of any IPR beyond that which has already been disclosed to the 
IETF and is referenced in your email.

  
Ron




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, April 7, 2022 3:10 PM
To: draft-ietf-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: Working Group Last Call IPR poll for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[External Email. Be cautious of content]

Authors,

The following IPR has been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-ip-flexalgo

Are you aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ip-flexalgo-04?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Peter,

I'm afraid that you have not answered Dan's question, or mine.

The word "architecture" does not appear in RFC 8919 or RFC 8920. What makes 
ASLA "the right thing"?

Is "the architecture" codified in some document? If not, is there an agreed 
upon architecture at all?

 Ron


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Friday, August 20, 2021 10:05 AM
To: Voyer, Daniel ; Voyer, Daniel 
; Jeff Tantsura ; Yingzhen Qu 

Cc: Les Ginsberg (ginsberg) ; Ron Bonica 
; Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]


Dan,

On 20/08/2021 15:22, Voyer, Daniel wrote:
> Peter,
>
> On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak"  on behalf of ppsenak=40cisco@dmarc.ietf.org> wrote:
>
>  Dan,
>
>  On 20/08/2021 14:14, Voyer, Daniel wrote:
>  > But generic-metric is a “new attribute” and is not in ASLA – RFC8919,
>  > why can’t we use TLV 22 again ?
>  because any new link attribute for which advertising application
>  specific values make sense should use ASLA encoding. Metric is
>  definitely such an attribute, similar to TE metric and delay (that is
>  used as metric for flex-algo).
>
> But technically what prevent us to use TLV 22 ? it's out there already

it's not about technically not being possible, it's about doing the right thing 
and following the existing architecture that has been defined for ASLA already.

thanks,
Peter

>
>  thanks,
>  Peter
>
>
>
>  >
>  > *From: *Lsr  on behalf of Jeff Tantsura
>  > 
>      > *Date: *Thursday, August 19, 2021 at 8:14 PM
>  > *To: *Yingzhen Qu 
>  > *Cc: *"Les Ginsberg (ginsberg)" ,
>  > Ron Bonica , "Acee Lindem (acee)"
>  > , "lsr@ietf.org" 
>  > *Subject: *[EXT]Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo
>  > BW Constraints
>  >
>  > we are going in rounds, +1 Les!
>  >
>  > Cheers,
>  >
>  > Jeff
>  >
>  > On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg)
>  >   > <mailto:ginsberg=40cisco@dmarc.ietf.org>> wrote:
>  >
>  > Ron -
>  >
>  > Indeed – it is long past the time when we should be focusing on
>  > the “big picture”.
>  >
>  > I think Acee has stated it as succinctly as anyone – let me
>  > repeat for emphasis:
>  >
>  > /“The LSR WG developed ASLAs to cover usage of the link
>  > attributes (including metrics) for different applications and
>  > mitigate all the vagaries of the original TE link attribute
>  > specifications. ASLAs are implemented and deployed. I believe 
> it
>  > would be a mistake to bifurcate the IGP standards with yet
>  > another way of encoding link attributes for different
>  > applications.”/
>  >
>  > ASLA is an architecture – one designed to assure that we can
>  > explicitly identify the set of applications using any link
>  > attribute . It is designed to be extensible both to new
>  > applications and to new attributes. It was long debated in the
>  > WG and underwent extensive review and is now standardized in
>  > RFCs 8919, 8920. It has been implemented and deployed and forms
>  > the basis of interoperable implementations.
>  >
>  > Now you (and others) decide to invent a new attribute. The
>  > attribute certainly can be advertised using ASLA, but instead 
> of
>  > acknowledging the existence of the ASLA architecture and
>  > defining the new attribute to use ASLA, you decide that maybe 
> if
>  > we advertise this attribute in some new way there might be some
>  > modest advantages. This ignores the consequences of having to
>  > implement attribute specific encoding rules in order to map
>  > attributes to applications. These consequences include greater
>  > code complexity and higher probability of interoperability 
> issues.
>  >
>  > And, based on your list of attributes below, what have we to
>  > look forward to? More attribute specific encoding rule

[Lsr] FW: New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Ron Bonica]

Folks,

Please review and comment.

Ron



Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, August 19, 2021 11:31 PM
> To: Chris Bowers ; Robert Raszuk
> ; Ron Bonica ; Shraddha Hegde
> ; Zhenbin Li 
> Subject: New Version Notification for draft-hegde-lsr-asla-any-app-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-hegde-lsr-asla-any-app-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-hegde-lsr-asla-any-app
> Revision:   00
> Title:  The Application Specific Link Attribute (ASLA) Any 
> Application Bit
> Document date:  2021-08-19
> Group:  Individual Submission
> Pages:  6
> URL:
> https://www.ietf.org/archive/id/draft-hegde-lsr-asla-any-app-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hegde-lsr-asla-any-app
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-asla-any-app
> 
> 
> Abstract:
>RFC 8919 and RFC 8920 define Application Specific Link Attributes
>(ASLA).  Each ASLA includes an Application Identifier Bit Mask.  The
>Application Identifier Bit Mask includes a Standard Application Bit
>Mask (SABM) and a User Defined Application Bit Mask (UDABM).  The
>SABM and UDABM determine which applications can use the ASLA as an
>input.
> 
>This document introduces a new bit to the Standard Application
>Identifier Bit Mask.  This bit is called the Any Application Bit
>(i.e., the A-bit).  If the A-bit is set, the link attribute can be
>used by any application.  This includes currently defined
>applications as well as applications to be defined in the future.
> 
> 
> 
> 
> The IETF Secretariat
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Robert,

The following information types need to be distributed :


  1.  Application Independent Link Attributes
 *   Mentioned in Section 3.2 of RFC 8919
 *   Not mentioned in Section 3.2 of RFC 8919
  2.  Application Configuration Information that is associated with an interface
  3.  Application Information that is not associated with an interface

Section 6.1 of RFC 8919 addresses information of Type 1a). Under some 
conditions, it can be advertised as described in RFC 5305. In other conditions, 
it must be advertised as ASLA.

Information of Type 1b) should by advertised as were the TE attributes defined 
in RFC 5305 (i.e., outside of the ASLA context).

Information of Type 2 should be advertises as ASLA.

Information of Type 3 should be considered on an application by application 
basis. For Flexalgo, it should be advertised in the FAD.


 Ron



Juniper Business Use Only
From: Robert Raszuk 
Sent: Tuesday, August 17, 2021 2:52 PM
To: Ron Bonica 
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Hi Ron,

Please kindly enlighten me on your line of thinking ...

Let's consider your list:

Total physical bandwidth
Number of LAG elements
Bandwidth of smallest lag member
Latency

Then as a method of distributing them you choose your option 3 which reads:

"Configure this information in a few central places and advertise it to all 
other nodes. The advertisement is not associated with a link. Flexalgo uses the 
FAD in this manner."

Question:

How can you configure any of the metrics you enumerated "in a few central 
places" irrespective on how we encode it in IGP ?  Isn't each of those 
properties local to each node which needs to be flooded via a domain from each 
node ?

Thx,
R.






On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Acee,

So, let us discuss whether there is a good reason for 
draft-ietf-lsr-flex-algo-con to specify ASLA !

Link attributes are different from application configuration information. Link 
attributes are properties of a link.  They are independent of the applications 
that use them. The following are examples:


  *   Total physical bandwidth
  *   Number of LAG elements
  *   Bandwidth of smallest lag member
  *   Latency

Link attributes do not benefit from ASLA encoding because they are not 
application specific.

Application configuration information constrains the behavior of an 
application. It can apply to:


  *   The application and a link
  *   The application only

Bandwidth reservation applies to an application and a link. For example, a link 
may advertise that it has:


  *   X Gbps available for RSVP-TE reservations
  *   Y Gbps available for SR Policy reservations
  *   Z Gbps available for TI-LFA reservations

This class of configuration information clearly benefits from ASLA encoding, 
because it is applicable to both the application and the link.

Some applications (e.g., Flexalgo) can be configured to use a variety of link 
attributes in SPF calculation. No matter how they acquire this configuration 
information, it MUST be the same at each node. Otherwise, routing loops may 
result. Configuration options are:


  1.  Configure this information on each link and advertise link attributes 
with ASLA
  2.  Configure this information on each node that runs the application
  3.  Configure this information in a few central places and advertise it to 
all other nodes. The advertisement is not associated with a link. Flexalgo uses 
the FAD in this manner.

Neither Option 1 nor Option 2 is very appealing, because it requires 
configuration on each node. Option 3 is better because:


  *   It requires configuration on only a few nodes
  *   It maintains separation between link attributes and application 
configuration information
  *   It can support applications like Flexalgo, where each algorithm may use 
different link attributes to calculate the shortest path


Ron





Juniper Business Use Only
From: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Sent: Friday, August 13, 2021 10:22 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG member:

Hi Ron,
My rationale is #1. The LSR WG developed ASLAs to cover usage of the link 
attributes (including metrics) for different applications and mitigate all the 
vagaries of the original TE link attribute specifications. ASLAs are 
implemented and deployed. I believe it would be a mistake to bifurcate the IGP 
standards with yet another w

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Acee,

So, let us discuss whether there is a good reason for 
draft-ietf-lsr-flex-algo-con to specify ASLA !

Link attributes are different from application configuration information. Link 
attributes are properties of a link.  They are independent of the applications 
that use them. The following are examples:


  *   Total physical bandwidth
  *   Number of LAG elements
  *   Bandwidth of smallest lag member
  *   Latency

Link attributes do not benefit from ASLA encoding because they are not 
application specific.

Application configuration information constrains the behavior of an 
application. It can apply to:


  *   The application and a link
  *   The application only

Bandwidth reservation applies to an application and a link. For example, a link 
may advertise that it has:


  *   X Gbps available for RSVP-TE reservations
  *   Y Gbps available for SR Policy reservations
  *   Z Gbps available for TI-LFA reservations

This class of configuration information clearly benefits from ASLA encoding, 
because it is applicable to both the application and the link.

Some applications (e.g., Flexalgo) can be configured to use a variety of link 
attributes in SPF calculation. No matter how they acquire this configuration 
information, it MUST be the same at each node. Otherwise, routing loops may 
result. Configuration options are:


  1.  Configure this information on each link and advertise link attributes 
with ASLA
  2.  Configure this information on each node that runs the application
  3.  Configure this information in a few central places and advertise it to 
all other nodes. The advertisement is not associated with a link. Flexalgo uses 
the FAD in this manner.

Neither Option 1 nor Option 2 is very appealing, because it requires 
configuration on each node. Option 3 is better because:


  *   It requires configuration on only a few nodes
  *   It maintains separation between link attributes and application 
configuration information
  *   It can support applications like Flexalgo, where each algorithm may use 
different link attributes to calculate the shortest path


Ron





Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Friday, August 13, 2021 10:22 AM
To: Ron Bonica ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG member:

Hi Ron,
My rationale is #1. The LSR WG developed ASLAs to cover usage of the link 
attributes (including metrics) for different applications and mitigate all the 
vagaries of the original TE link attribute specifications. ASLAs are 
implemented and deployed. I believe it would be a mistake to bifurcate the IGP 
standards with yet another way of encoding link attributes for different 
applications.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Ron 
Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Date: Thursday, August 12, 2021 at 3:46 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

Acee,

Please help me to parse your message. It is clear that you want 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA's. However, your rationale is 
not so clear.

It is not because RFC 8919 mandates ASLA. In fact, we agree that it would be 
strange for an RFC to include a mandate that precludes future proposals.

Are any of the following your rationale:


1) Because there is a good technical reason for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA

2) Because it is possible, but not necessary, for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA

3) Because it was the unstated intention of RFC 8919 to include a mandate 
that precludes future proposals (although we agree that this would be strange).

For the purposes of full disclosure, I think discussion regarding the first 
rationale would be fruitful. However, I don't think very much of the second or 
third rationale.


Ron





Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 10, 2021 4:43 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG Member:

  In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism was 
to be used for new link attributes and applications. While the documents do not 
mandate that there never could be a new way to advertise link attributes, this 
was clearly the intent. Indeed, it would be 

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Acee,

Please help me to parse your message. It is clear that you want 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA's. However, your rationale is 
not so clear.

It is not because RFC 8919 mandates ASLA. In fact, we agree that it would be 
strange for an RFC to include a mandate that precludes future proposals.

Are any of the following your rationale:


  1.  Because there is a good technical reason for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA
  2.  Because it is possible, but not necessary, for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA
  3.  Because it was the unstated intention of RFC 8919 to include a mandate 
that precludes future proposals (although we agree that this would be strange).

For the purposes of full disclosure, I think discussion regarding the first 
rationale would be fruitful. However, I don't think very much of the second or 
third rationale.


Ron





Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 10, 2021 4:43 PM
To: lsr@ietf.org
Subject: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG Member:

  In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism was 
to be used for new link attributes and applications. While the documents do not 
mandate that there never could be a new way to advertise link attributes, this 
was clearly the intent. Indeed, it would be strange for an RFC to include a 
mandate that precluded future proposals. The advertisement enablement and 
deployment sections of these documents specifically cover future attributes and 
applications.

  Given that we have ASLAs as building blocks, I don't really see a reason to 
introduce the generic metric. The proponents say it isn't an alternative to 
ASLAs but their examples cite different applications using different metric 
types (i.e., application-specific metrics). Also, given that ASLA are used by 
the base Flex Algo draft, it would be inconsistent to diverge for Flex Algo BW 
constraints.

  Consequently, I would request that draft-ietf-lsr-flex-algo-bw-con-01 revert 
to using ASLAs. Based on the LSR Email discussion prior to IETF 111, this was 
definitely the consensus.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Rtgdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Ron Bonica via Datatracker]

Reviewer: Ron Bonica
Review result: Ready

Good idea!


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Generic metric: application-specific vs application-independent

[Ron Bonica]

Gunter,

I think we agree that some link attributes are application specific while 
others are application independent. However, it is not so easy to figure out 
which link attributes should be assigned to each category.

In your message below, you suggest that any attribute whose value is learned 
from configuration is application specific. But wouldn't the following 
attributes break that model, if we ever needed to advertise them:

- Circuit mileage
- monetary cost

We might have to decide whether link attributes are application specific or 
application independent on a case-by-case basis.

 Ron





Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: Friday, July 30, 2021 5:06 AM
To: Peter Psenak ; Shraddha Hegde 
; Les Ginsberg (ginsberg) 
; Tony Li 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]


A little late in the discussion... (PTO events do happen)

a quick opinion on the below discussion on whether Generic metric sub-tlv 
should be encoded on a ASLA or not.
For me, it depends on how the metric for the corresponding metric-type is 
obtained and if it can be configured (static).
It doesn’t make sense to have Application specific values if a particular 
metric is obtained only dynamically, for eg, dynamically measured delay is 
going to be same for all applications.
On the contrary, te-metric can be configured, and we can in principle configure 
different values for different applications.

My opinion is that if any of the metric-types in the Generic metric sub-tlv can 
be configured, it should be inside the ASLA.

G/

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Friday, July 30, 2021 9:42 AM
To: Shraddha Hegde ; Les Ginsberg 
(ginsberg) ; Tony Li 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

Shraddha,

On 30/07/2021 06:53, Shraddha Hegde wrote:
> Operators have built their networks with link attributes
>
> being configured and used by any application. For example
>
> igp-metric is used by ISIS, then came LDP that used same igp-metric,
>
> RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
>
> and even flex-algo. All these applications could use the same igp-metric.
>
> The networks have evolved like this for 20-30 years.
>
> If an operator wants to design his network for this kind of
>
> network evolution with generic metric going forward, ASLA does not
>
> currently provide an effective solution.

please be more specific as to what exactly "ASLA does not currently provide an 
effective solution" for.

> ASLA currently has limitations
>
> that make it more complex than necessary for operators who want to
>
> evolve their networks this way.

above seems more like your opinion than the fact. I have not seen any evidence 
that would prove the above statement.


>
> I am working on a draft to propose improvements to ASLA to
>
> make this kind of evolution less complex. I'll post a draft
>
> soon that will describe limitations of ASLA in its current form
>
> along with proposed improvements.


hard to comment on something that does not exist.


>
> I would still like to hear about use cases that require
>
> generic metric to be applications-specific and cannot be solved with
>
> application-independent generic metric.

it has been explained on the list multiple times.


thanks,
Peter


>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* Les Ginsberg (ginsberg) 
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Shraddha Hegde 
> *Subject:* RE: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> *[External Email. Be cautious of content]*
>
> Tony –
>
> You ask very important questions – but – as Acee has answered in a 
> subsequent email – all of these questions were openly debated in the 
> WG during the work on what became RFC8919/8920. This debate was 
> contentious, took years, and the WG eventually reached consensus on 
> what became the two RFCs.
>
> If every time a new attribute is defined we reopen the original 
> debate, then we will never move forward and we will have great 
> difficulty in deploying interoperable implementations.
>
> I can respect that you might have preferred a different conclusion on 
> the part of the WG – but I hope you will also acknowledge that this is 
> now a resolved issue and we need to move forward following the 
> existing RFCs.
>
> Parenthetically, I do believe that answers to your questions can be 
> found in the RFCs. The answers may not satisfy you – but we did 
> attempt to include the context which drove the ASLA solution.
>
> Thanx.
>
>  Les
>
> *From:* Lsr mailto:lsr-boun...@ietf.org>> *On 
> Behalf Of *Tony Li
> *Sent:* Wednesday, July 28, 2021 1:06 

Re: [Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Ron Bonica]

Peter,

I agree that we will need to update the flexago draft. But before we do that, 
can you explain why we need to maintain mandatory use of ASLA?

AFAIKS, by their nature, some attributes are generic while others are 
application specific. For example, a link's total physical bandwidth is 
generic, by nature. It will always be the same for all applications. By 
contrast, the amount of bandwidth available to a specific application is 
application specific, by nature. It can be different for each application.

  Ron




Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Monday, July 26, 2021 2:45 PM
To: Ron Bonica ; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; Shraddha Hegde ; 
gregory.mir...@ztetx.com; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
draft-ietf-lsr-flex-algo-bw-con-01.txt)

[External Email. Be cautious of content]


Hi Ron,

On 26/07/2021 20:30, Ron Bonica wrote:
> Peter,
>
> I think that we are using the term "link attribute" differently. IMO, a link 
> attribute is any attribute of a link, regardless of whether it is advertised 
> in the fixed portion of a link advertisement or in a TLV.
>
> Are you assuming otherwise? If so, why?

when we are talking about the advertisement of the link attributes, we are 
talking about something that is advertised separately and optionally, not 
something that is part of the fixed portion of the link advertisement.

If that is not clear, I can make that statement in the flex-algo draft, but 
that would not remove the mandatory usage of the ASLA for the
(optional) attributes.


thanks,
Peter

>
> Ron
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, July 26, 2021 1:31 PM
> To: Ron Bonica ; Acee Lindem (acee) 
> ; Les Ginsberg (ginsberg) 
> ; Shraddha Hegde ; 
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-01.txt)
>
> [External Email. Be cautious of content]
>
>
> Hi Ron,
>
> On 26/07/2021 18:36, Ron Bonica wrote:
>> Acee,
>>
>> We may also need to clean up an inconsistency in 
>> draft-ietf-lsr-flex-algo-17. Section 12 of that document says:
>>
>> "   Link attribute advertisements that are to be used during Flex-
>>  Algorithm calculation MUST use the Application-Specific Link
>>  Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
>>  unless, in the case of IS-IS, the L-Flag is set in the ASLA
>>  advertisement.  If the L-Flag is set, as defined in [RFC8919]
>>  Section 4.2 subject to the constraints discussed in Section 6 of the
>>  [[RFC8919], then legacy advertisements are to be used instead. "
>>
>> However, Flex-Algorithm calculations include the IGP metric.
>
>
> IGP metric is not advertised as a link attribute, it is part of the fixed 
> portion of the link advertisement. So the above text is not affecting the 
> usage if the IGP metric.
>
> thanks,
> Peter
>
>
>>
>>
>> Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>> -Original Message-
>> From: Acee Lindem (acee) 
>> Sent: Friday, July 23, 2021 10:13 AM
>> To: Ron Bonica ; Les Ginsberg (ginsberg) 
>> ; Shraddha Hegde ; 
>> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; 
>> lsr@ietf.org
>> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
>> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Ron,
>>
>> So perhaps, generic metric is not a legacy advertisement as strictly 
>> defined. However, we don't want to go down the path of treating new 
>> attributes in the same manner as legacy attributes. It seems the discussion 
>> is progressing and hopefully we will have a resolution.
>>
>> Thanks,
>> Acee
>>
>> On 7/22/21, 1:28 PM, "Ron Bonica"  
>> wrote:
>>
>>   Acee,
>>
>>   I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
>>
>>   Section 6.1 of RFC 8919 says:
>>
>>   " New applications that future documents define to make use of the
>>  advertisements defined in this document MUST NOT make use of legacy
>>  advertisements.  This simplifies deployment of new applications by
>>  elim

Re: [Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Ron Bonica]

Peter,

I think that we are using the term "link attribute" differently. IMO, a link 
attribute is any attribute of a link, regardless of whether it is advertised in 
the fixed portion of a link advertisement or in a TLV. 

Are you assuming otherwise? If so, why?

   Ron



Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Monday, July 26, 2021 1:31 PM
To: Ron Bonica ; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; Shraddha Hegde ; 
gregory.mir...@ztetx.com; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
draft-ietf-lsr-flex-algo-bw-con-01.txt)

[External Email. Be cautious of content]


Hi Ron,

On 26/07/2021 18:36, Ron Bonica wrote:
> Acee,
>
> We may also need to clean up an inconsistency in draft-ietf-lsr-flex-algo-17. 
> Section 12 of that document says:
>
> "   Link attribute advertisements that are to be used during Flex-
> Algorithm calculation MUST use the Application-Specific Link
> Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
> unless, in the case of IS-IS, the L-Flag is set in the ASLA
> advertisement.  If the L-Flag is set, as defined in [RFC8919]
> Section 4.2 subject to the constraints discussed in Section 6 of the
> [[RFC8919], then legacy advertisements are to be used instead. "
>
> However, Flex-Algorithm calculations include the IGP metric.


IGP metric is not advertised as a link attribute, it is part of the fixed 
portion of the link advertisement. So the above text is not affecting the usage 
if the IGP metric.

thanks,
Peter


>
> 
> Ron
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Friday, July 23, 2021 10:13 AM
> To: Ron Bonica ; Les Ginsberg (ginsberg) 
> ; Shraddha Hegde ; 
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; 
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
> [External Email. Be cautious of content]
>
>
> Hi Ron,
>
> So perhaps, generic metric is not a legacy advertisement as strictly defined. 
> However, we don't want to go down the path of treating new attributes in the 
> same manner as legacy attributes. It seems the discussion is progressing and 
> hopefully we will have a resolution.
>
> Thanks,
> Acee
>
> On 7/22/21, 1:28 PM, "Ron Bonica"  
> wrote:
>
>  Acee,
>
>  I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
>
>  Section 6.1 of RFC 8919 says:
>
>  " New applications that future documents define to make use of the
> advertisements defined in this document MUST NOT make use of legacy
> advertisements.  This simplifies deployment of new applications by
> eliminating the need to support multiple ways to advertise attributes
> for the new applications."
>
>  Section 3 of RFC 8919 defines legacy advertisements. The definition of 
> legacy
>  advertisements does not include new attributes such as
>  generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not
>  violate RFC 8919
>
>  Relevant text from Section 3 of RFC 8919 is included below for 
> convenience.
>
>
> Ron
>
>
>  RFC 8919, Section 3
>  ---
>  3.  Legacy Advertisements
>
>
>  Existing advertisements used in support of RSVP-TE include sub-TLVs
> for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
> Group (SRLG) advertisement.
>
> Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
> 222, and 223" registry.
>
> TLVs are defined in the "TLV Codepoints Registry".
>
>  3.1.  Legacy Sub-TLVs
>
> +==++
> | Type | Description|
> +==++
> | 3| Administrative group (color)   |
> +--++
> | 9| Maximum link bandwidth |
> +--++
> | 10   | Maximum reservable link bandwidth  |
> +--++
> | 11   | Unreserved bandwidth   |
> +--++
> | 14   | Extend

[Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Ron Bonica]

Acee,

We may also need to clean up an inconsistency in draft-ietf-lsr-flex-algo-17. 
Section 12 of that document says:

"   Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
   unless, in the case of IS-IS, the L-Flag is set in the ASLA
   advertisement.  If the L-Flag is set, as defined in [RFC8919]
   Section 4.2 subject to the constraints discussed in Section 6 of the
   [[RFC8919], then legacy advertisements are to be used instead. "

However, Flex-Algorithm calculations include the IGP metric.

   Ron



Juniper Business Use Only

-Original Message-
From: Acee Lindem (acee)  
Sent: Friday, July 23, 2021 10:13 AM
To: Ron Bonica ; Les Ginsberg (ginsberg) 
; Shraddha Hegde ; 
gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; 
lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[External Email. Be cautious of content]


Hi Ron,

So perhaps, generic metric is not a legacy advertisement as strictly defined. 
However, we don't want to go down the path of treating new attributes in the 
same manner as legacy attributes. It seems the discussion is progressing and 
hopefully we will have a resolution.

Thanks,
Acee

On 7/22/21, 1:28 PM, "Ron Bonica"  wrote:

Acee,

I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.

Section 6.1 of RFC 8919 says:

" New applications that future documents define to make use of the
   advertisements defined in this document MUST NOT make use of legacy
   advertisements.  This simplifies deployment of new applications by
   eliminating the need to support multiple ways to advertise attributes
   for the new applications."

Section 3 of RFC 8919 defines legacy advertisements. The definition of 
legacy
advertisements does not include new attributes such as
generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not
violate RFC 8919

Relevant text from Section 3 of RFC 8919 is included below for convenience.

  Ron


RFC 8919, Section 3
---
3.  Legacy Advertisements


Existing advertisements used in support of RSVP-TE include sub-TLVs
   for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
   Group (SRLG) advertisement.

   Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
   222, and 223" registry.

   TLVs are defined in the "TLV Codepoints Registry".

3.1.  Legacy Sub-TLVs

   +==++
   | Type | Description|
   +==++
   | 3| Administrative group (color)   |
   +--++
   | 9| Maximum link bandwidth |
   +--++
   | 10   | Maximum reservable link bandwidth  |
   +--++
   | 11   | Unreserved bandwidth   |
   +--++
   | 14   | Extended Administrative Group  |
   +--++
   | 18   | TE Default Metric  |
   +--++
   | 33   | Unidirectional Link Delay  |
   +--++
   | 34   | Min/Max Unidirectional Link Delay  |
   +--++
   | 35   | Unidirectional Delay Variation |
   +--++
   | 36   | Unidirectional Link Loss   |
   +--++
   | 37   | Unidirectional Residual Bandwidth  |
   +--++
   | 38   | Unidirectional Available Bandwidth |
   +--++
   | 39   | Unidirectional Utilized Bandwidth  |
   +--++

   Table 1: Sub-TLVs for TLVs 22, 23, 25,
 141, 222, and 223



Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 20, 2021 1:21 PM
To: Les Ginsberg (ginsberg) ; Shraddha 
Hegde ; gregory.mir...@ztetx.com; 
ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[External Email. Be cautious of content]


Speaking as WG member:

I agree with Les. The Gener

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Ron Bonica]

Les,

Please, let us avoid discussion of whether my message is disingenuous. As Acee 
will agree, discussion of my internal motivations and moral deficiencies is 
beyond the scope of the LSR WG.

Now, let us address my point and your counter points. My point was that 
draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, 
nothing less.

In your counterpoint #1, you point out tension between 
draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this point 
deserves discussion, it is orthogonal to my point. It is entirely possible that 
both of the following statements are true:

- draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
- there is tension between draft-ietf-lsr-flex-algo-bw-con and 
draft-ietf-lsr-flex-algo

In your counterpoint #2, you talk about the "clear intent" of RFC 8919. Section 
6.1 of RFC 8919 reduces that intent to a few very clear normative statements. 
Draft-ietf-lsr-flex-algo-bw-con does not violate any of those normative 
statements. Therefore, it does not violate RFC 8919.

You may say:

- Section 6.1 should have included more prohibitions
- The authors had additional prohibitions in mind when they wrote the draft, 
but failed to add them to Section 6.1

That's all fine, but the community agreed only to the words on the page, not 
the authors larger intent.


  Ron





Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Thursday, July 22, 2021 2:49 PM
To: Ron Bonica ; Acee Lindem (acee) ; 
Shraddha Hegde ; gregory.mir...@ztetx.com; Peter Psenak 
(ppsenak) ; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[External Email. Be cautious of content]


Ron -

With respect, it is hard to read your email without feeling that it is 
disingenuous.

But, let's cover the relevant points nonetheless.

Point #1:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$
  states:

" Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."

As the new generic-metric is intended for use by flex-algo it needs to conform 
to this normative statement.

Point #2:

RFC 8919 and 8920 were written to address ambiguities associated with the use 
of multiple applications.
The Introduction sections of both documents discuss this in some detail.

The clear intent is to make use of ASLA going forward - not to restrict ASLA 
only to the set of link attributes defined at the time of the writing of the 
RFCs. Failure to do so would reintroduce the same set of issues that RFC 
8919/8920 were written to address.
Your attempt to infer that because Generic-Metric was not defined at the time 
that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense.
ASLA is in fact a revision to the link attribute architecture and is meant to 
be used going forward.

The more appropriate question to ask is why we need to define a legacy style 
sub-TLV for new link attributes? Ketan has made this point in his post on this 
thread and I have sympathy with his position.

We do understand that legacy applications such as RSVP-TE may continue to be 
deployed in networks for some time to come. It is not reasonable to expect that 
legacy application implementations will be updated to use ASLA, which is why I 
do not object to defining a legacy style encoding for Generic Metric if folks 
believe that legacy applications may be enhanced to support new link attributes.

I strongly disagree with your interpretation that ASLA is limited only to the 
code points defined in RFC 8919/8920.

   Les


> -Original Message-
> From: Ron Bonica 
> Sent: Thursday, July 22, 2021 10:28 AM
> To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
> ; Shraddha Hegde ; 
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; 
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
> Acee,
>
> I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.
>
> Section 6.1 of RFC 8919 says:
>
> " New applications that future documents define to make use of the
>advertisements defined in this document MUST NOT make use of legacy
>advertisements.  This simplifies deployment of new applications by
>eliminating the need to support multiple ways to advertise attributes
>for the new applications."
>
> Section 3 of RFC 8919 defines legacy advertisements. The definition of 
> legacy advertisements doe

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Ron Bonica]

Acee,

I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.

Section 6.1 of RFC 8919 says:

" New applications that future documents define to make use of the
   advertisements defined in this document MUST NOT make use of legacy
   advertisements.  This simplifies deployment of new applications by
   eliminating the need to support multiple ways to advertise attributes
   for the new applications."

Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy 
advertisements does not include new attributes such as 
generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not 
violate RFC 8919

Relevant text from Section 3 of RFC 8919 is included below for convenience.

  Ron


RFC 8919, Section 3
---
3.  Legacy Advertisements


Existing advertisements used in support of RSVP-TE include sub-TLVs
   for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
   Group (SRLG) advertisement.

   Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
   222, and 223" registry.

   TLVs are defined in the "TLV Codepoints Registry".

3.1.  Legacy Sub-TLVs

   +==++
   | Type | Description|
   +==++
   | 3| Administrative group (color)   |
   +--++
   | 9| Maximum link bandwidth |
   +--++
   | 10   | Maximum reservable link bandwidth  |
   +--++
   | 11   | Unreserved bandwidth   |
   +--++
   | 14   | Extended Administrative Group  |
   +--++
   | 18   | TE Default Metric  |
   +--++
   | 33   | Unidirectional Link Delay  |
   +--++
   | 34   | Min/Max Unidirectional Link Delay  |
   +--++
   | 35   | Unidirectional Delay Variation |
   +--++
   | 36   | Unidirectional Link Loss   |
   +--++
   | 37   | Unidirectional Residual Bandwidth  |
   +--++
   | 38   | Unidirectional Available Bandwidth |
   +--++
   | 39   | Unidirectional Utilized Bandwidth  |
   +--++

   Table 1: Sub-TLVs for TLVs 22, 23, 25,
 141, 222, and 223



Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 20, 2021 1:21 PM
To: Les Ginsberg (ginsberg) ; Shraddha 
Hegde ; gregory.mir...@ztetx.com; 
ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[External Email. Be cautious of content]


Speaking as WG member:

I agree with Les. The Generic Metric MUST be advertised as an ASLA for usage in 
Flex Algorithm. Additionally, it may be advertised as a sub-TLV in IS-IS link 
TLVs. However, the latter encoding really shouldn't be used for new 
applications (at least that is my reading of RFC 8919).

For OSPF, I'd certainly hope one wouldn't originate additional LSAs when an 
ASLA can support the legacy applications with the ASLA mask.

Thanks,
Acee

 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ron Bonica]

Support




Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, May 12, 2021 5:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Ron Bonica]

Acee,

I am aware of IPR. It has been filed at https://datatracker.ietf.org/ipr/4317/.

  Ron




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Tuesday, December 1, 2020 4:21 PM
To: draft-bonica-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" 
- draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-01.txt

[Ron Bonica]

FYI


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Sunday, November 15, 2020 6:52 PM
> To: Shraddha Hegde ; Peter Psenak
> ; Ron Bonica ; Parag Kaneriya
> ; Rajesh M ; William Britto A J
> 
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-lsr-ip-flexalgo
> Revision:   01
> Title:  IGP Flexible Algorithms (Flex-Algorithm) In IP Networks
> Document date:  2020-11-15
> Group:  Individual Submission
> Pages:  17
> URL:
> https://www.ietf.org/archive/id/draft-bonica-lsr-ip-flexalgo-01.txt
> Status:
>  https://datatracker.ietf.org/doc/draft-bonica-lsr- ip-flexalgo
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft bonica-lsr-ip-flexalgo


> Abstract:
>An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
>constraint-based paths.  As currently defined, IGP Flex-Algorithm is
>used with Segment Routing (SR) data planes - SR MPLS and SRv6.
>Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
> 
>This document extends IGP Flex-Algorithm, so that it can be used for
>regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be
>deployed in any IP network, even in the absence of SR.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Jeff,

I think that you mean the scope is different. 

 Ron



Juniper Business Use Only

-Original Message-
From: Jeff Tantsura  
Sent: Saturday, October 10, 2020 3:14 PM
To: Ron Bonica 
Cc: Dongjie (Jimmy) ; Peter Psenak ; 
Yingzhen Qu ; Gyan Mishra ; 
lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Jie,

The scoop is different, for SR data plane entry uniqueness is in context of SR 
domain (SID = value + context), while for IP it is global to the routing 
domain, FIB entry is a destination, nothing more.

Regards,
Jeff

> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
>
> Hi Jimmie,
>
> Inline.
>
>Ron
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Dongjie (Jimmy) 
> Sent: Friday, October 9, 2020 11:06 PM
> To: Peter Psenak ; Ron Bonica 
> ; Yingzhen Qu ; Gyan 
> Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: RE: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
>
> Hi Peter,
>
> Thanks for your reply. It aligns with my understanding of FAD, which is just 
> a set of constraints for path computation. Thus one Flex-Algo ID could be 
> used with multiple different data planes. Is this understanding correct?
>
> [RB] I never thought about this. Is there a use-case? I think that it will 
> work, but I would have to try it before saying for sure.
>
> If so, my question is about the scenario below:
>
> A group of nodes in a network support FA-128, a sub-group of them bind FA-128 
> to SR SIDs, another sub-group of them bind FA-128 to IP address. When one 
> node compute an SR path to a destination, can it compute the path to only 
> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind 
> FA-128 to IP address?
>
> [RB] I don't think so. However, you could achieve the same outcome using link 
> colors.
>
> If so, how could this node know the binding of FA to different data planes on 
> other nodes?
>
> Best regards,
> Jie
>
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Friday, October 9, 2020 11:58 PM
>> To: Dongjie (Jimmy) ; Ron Bonica 
>> ; Yingzhen Qu 
>> ; Gyan Mishra 
>> Cc: lsr@ietf.org; Jeff Tantsura 
>> Subject: Re: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> Hi Jimmy,
>>
>>
>>>  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>> Hi Ron,
>>>
>>> Thanks for explaining the difference between IP Flex-Algo and SR 
>>> Flex-algo. As
>> you said, the major difference is the data plane.
>>>
>>> If my understanding is correct, for one Flex-Algo to be used 
>>> correctly, the set
>> of nodes need to apply consistent constraints in computation, and 
>> bind the FAD to the same data plane.
>>>
>>> Is it possible that different nodes may use the same Flex-Algo with 
>>> different
>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with 
>> pure IP etc., or each Flex-Algo is always associated with only one 
>> data plane? In the former case, should the flex-algo definition also 
>> indicate the data plane(s) to be used with the flex-algo?
>>
>> let me respond to this query, as this is not specific to Ron's draft.
>>
>> FAD is data plane agnostic and is used by all of them.
>>
>> thanks,
>> Peter
>>
>>>
>>> Best regards,
>>> Jie
>>>
>>>> -Original Message-
>>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>> To: Yingzhen Qu ; Peter Psenak 
>>>> ; Gyan Mishra 
>>>> Cc: lsr@ietf.org; Jeff Tantsura 
>>>> Subject: Re: [Lsr] FW: New Version Notification for 
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>
>>>> Hi Yingzhen,
>>>>
>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the 
>>>> following
>> respects:
>>>>
>>>> - Links have IGP metrics, TE metrics, delay metrics and 
>>>> administrative colors
>>>> - FADs define Flexible Algorithms
>>>>
>>>> More specifically, the FAD:
>>>>
>>>> - Indicates which metric type the Flexible Algorithm uses
>>>> - Specifies constraints in terms of link colors that are included 
>>>

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Hi Jimmie,

Inline.

Ron


Juniper Business Use Only

-Original Message-
From: Dongjie (Jimmy)  
Sent: Friday, October 9, 2020 11:06 PM
To: Peter Psenak ; Ron Bonica ; 
Yingzhen Qu ; Gyan Mishra 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: RE: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Hi Peter,

Thanks for your reply. It aligns with my understanding of FAD, which is just a 
set of constraints for path computation. Thus one Flex-Algo ID could be used 
with multiple different data planes. Is this understanding correct?

[RB] I never thought about this. Is there a use-case? I think that it will 
work, but I would have to try it before saying for sure.

If so, my question is about the scenario below:

A group of nodes in a network support FA-128, a sub-group of them bind FA-128 
to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node 
compute an SR path to a destination, can it compute the path to only pass the 
nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP 
address? 

[RB] I don't think so. However, you could achieve the same outcome using link 
colors.

If so, how could this node know the binding of FA to different data planes on 
other nodes?

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, October 9, 2020 11:58 PM
> To: Dongjie (Jimmy) ; Ron Bonica 
> ; Yingzhen Qu 
> ; Gyan Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> Hi Jimmy,
>
>
>   On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > Hi Ron,
> >
> > Thanks for explaining the difference between IP Flex-Algo and SR 
> > Flex-algo. As
> you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used 
> > correctly, the set
> of nodes need to apply consistent constraints in computation, and bind 
> the FAD to the same data plane.
> >
> > Is it possible that different nodes may use the same Flex-Algo with 
> > different
> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure 
> IP etc., or each Flex-Algo is always associated with only one data 
> plane? In the former case, should the flex-algo definition also 
> indicate the data plane(s) to be used with the flex-algo?
>
> let me respond to this query, as this is not specific to Ron's draft.
>
> FAD is data plane agnostic and is used by all of them.
>
> thanks,
> Peter
>
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Sunday, October 4, 2020 4:34 AM
> >> To: Yingzhen Qu ; Peter Psenak 
> >> ; Gyan Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for 
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Yingzhen,
> >>
> >> IP Flexible Algorithms are like SR Flexible Algorithms in the 
> >> following
> respects:
> >>
> >> - Links have IGP metrics, TE metrics, delay metrics and 
> >> administrative colors
> >> - FADs define Flexible Algorithms
> >>
> >> More specifically, the FAD:
> >>
> >> - Indicates which metric type the Flexible Algorithm uses
> >> - Specifies constraints in terms of link colors that are included 
> >> or excluded from the Flexible Algorithm.
> >>
> >> The significant difference between IP Flexible Algorithms and SR 
> >> Flexible Algorithms is:
> >>
> >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
> >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
> >>
> >> So, IP Flexible Algorithms can be deployed in any IP network, even 
> >> in the absence of SR.
> >>
> >>  Ron
> >>
> >>
> >> Juniper Business Use Only
> >>
> >> -Original Message-
> >> From: Yingzhen Qu 
> >> Sent: Saturday, October 3, 2020 2:08 PM
> >> To: Peter Psenak ; Gyan Mishra 
> >> ; Ron Bonica 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for 
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Hi Peter,
> >>
> >> Using flex-algo, a SRv6 locator can

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

+1


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Friday, October 9, 2020 11:58 AM
To: Dongjie (Jimmy) ; Ron Bonica ; 
Yingzhen Qu ; Gyan Mishra 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Hi Jimmy,


  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> Hi Ron,
>
> Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. 
> As you said, the major difference is the data plane.
>
> If my understanding is correct, for one Flex-Algo to be used correctly, the 
> set of nodes need to apply consistent constraints in computation, and bind 
> the FAD to the same data plane.
>
> Is it possible that different nodes may use the same Flex-Algo with different 
> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP 
> etc., or each Flex-Algo is always associated with only one data plane? In the 
> former case, should the flex-algo definition also indicate the data plane(s) 
> to be used with the flex-algo?

let me respond to this query, as this is not specific to Ron's draft.

FAD is data plane agnostic and is used by all of them.

thanks,
Peter

>
> Best regards,
> Jie
>
>> -Original Message-----
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
>> Sent: Sunday, October 4, 2020 4:34 AM
>> To: Yingzhen Qu ; Peter Psenak 
>> ; Gyan Mishra 
>> Cc: lsr@ietf.org; Jeff Tantsura 
>> Subject: Re: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> Hi Yingzhen,
>>
>> IP Flexible Algorithms are like SR Flexible Algorithms in the following 
>> respects:
>>
>> - Links have IGP metrics, TE metrics, delay metrics and 
>> administrative colors
>> - FADs define Flexible Algorithms
>>
>> More specifically, the FAD:
>>
>> - Indicates which metric type the Flexible Algorithm uses
>> - Specifies constraints in terms of link colors that are included or 
>> excluded from the Flexible Algorithm.
>>
>> The significant difference between IP Flexible Algorithms and SR 
>> Flexible Algorithms is:
>>
>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
>>
>> So, IP Flexible Algorithms can be deployed in any IP network, even in 
>> the absence of SR.
>>
>>  Ron
>>
>>
>> Juniper Business Use Only
>>
>> -Original Message-
>> From: Yingzhen Qu 
>> Sent: Saturday, October 3, 2020 2:08 PM
>> To: Peter Psenak ; Gyan Mishra 
>> ; Ron Bonica 
>> Cc: lsr@ietf.org; Jeff Tantsura 
>> Subject: Re: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Peter,
>>
>> Using flex-algo, a SRv6 locator can be associated with a single algo, 
>> which means an IPv6 or IPv4 address can also be associated with a 
>> single algo. So my understanding is Ron's proposal is making the 
>> configuration of flex-algo easier?
>> Instead of using the exclude or include list you can configure a 
>> loopback address to a flex-algo directly?
>>
>> Thanks,
>> Yingzhen
>>
>> On 10/3/20, 2:47 AM, "Peter Psenak"  wrote:
>>
>>  Hi Yingzhen,
>>
>>  On 02/10/2020 22:15, Yingzhen Qu wrote:
>>  > Hi Peter,
>>  >
>>  > My understanding of flex-algo is that for traffic destined to 
>> a prefix on a particular algo, it can only be routed on routers 
>> belong to that algo, which also means only routers in that algo 
>> calculates how to reach that prefix and install it into the routing 
>> table. It seems to me that using flex-algo (section 12 of the
>> draft) it's possible to have a loopback address associated with only 
>> one algo, please correct me if I'm missing or misunderstood something.
>>
>>  you are right. That is exactly what is being done for flex-algo with
>>  SRv6 - locator is associated with a single algo only. The proposal uses
>>  the same concept.
>>
>>  thanks,
>>  Peter
>>
>>  >
>>  > Thanks,
>>  > Yingzhen
>>  >
>>  > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
>> > ppsenak=40cisco@dmarc.ietf.org>
>> wrote:
>>  >
>>  >  Gyan,
>>  >
>>  >

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Hi Yingzhen,

IP Flexible Algorithms are like SR Flexible Algorithms in the following 
respects:

- Links have IGP metrics, TE metrics, delay metrics and administrative colors
- FADs define Flexible Algorithms

More specifically, the FAD:

- Indicates which metric type the Flexible Algorithm uses
- Specifies constraints in terms of link colors that are included or excluded 
from the Flexible Algorithm.

The significant difference between IP Flexible Algorithms and SR Flexible 
Algorithms is:

- SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
- IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.

So, IP Flexible Algorithms can be deployed in any IP network, even in the 
absence of SR.

Ron


Juniper Business Use Only

-Original Message-
From: Yingzhen Qu  
Sent: Saturday, October 3, 2020 2:08 PM
To: Peter Psenak ; Gyan Mishra ; Ron 
Bonica 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Hi Peter,

Using flex-algo, a SRv6 locator can be associated with a single algo, which 
means an IPv6 or IPv4 address can also be associated with a single algo. So my 
understanding is Ron's proposal is making the configuration of flex-algo 
easier? Instead of using the exclude or include list you can configure a 
loopback address to a flex-algo directly?

Thanks,
Yingzhen

On 10/3/20, 2:47 AM, "Peter Psenak"  wrote:

Hi Yingzhen,

On 02/10/2020 22:15, Yingzhen Qu wrote:
> Hi Peter,
>
> My understanding of flex-algo is that for traffic destined to a prefix on 
a particular algo, it can only be routed on routers belong to that algo, which 
also means only routers in that algo calculates how to reach that prefix and 
install it into the routing table. It seems to me that using flex-algo (section 
12 of the draft) it's possible to have a loopback address associated with only 
one algo, please correct me if I'm missing or misunderstood something.

you are right. That is exactly what is being done for flex-algo with
SRv6 - locator is associated with a single algo only. The proposal uses
the same concept.

thanks,
Peter

>
> Thanks,
> Yingzhen
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" 
 wrote:
>
>  Gyan,
>
>  On 02/10/2020 18:30, Gyan Mishra wrote:
>  > All,
>  >
>  > With SRv6 and IP based flex algo a generic question as it applies 
to
>  > both. Is it possible to have within a single IGP domain different 
sets
>  > of nodes or segments of the network running different algorithms.
>
>  absolutely.
>
>  > From
>  > both drafts it sounds like all nodes have to agree on same 
algorithm
>  > similar to concept of metric and reference bandwidth all have to 
have
>  > the same style metric and play to the same sheet of music.
>
>  all participating nodes need to agree on the definition of the 
flex-algo
>  and advertise the participation. That's it.
>
>  > If there was
>  > a way to use multiple algorithms simultaneously based on SFC or 
services
>  > and instantiation of specific algorithm based on service to be
>  > rendered.  Doing so without causing a routing loop or sub optimal
>  > routing.
>
>  you can certainly use multiple algorithms simultaneously and use algo
>  specific paths to forward specific traffic over it. How that is done
>  from the forwarding perspective depends in which forwarding plane you
>  use. Flex-algo control plane is independent of the forwarding plane.
>
>
>  >I thought with flex algo that there exists a feature that on
>  > each hop there is a way to specify which algo to use hop by hop 
similar
>  > to a hop by hop policy based routing.
>
>  no, there is no hop-by-hop classification, that is problematic and 
does
>  not scale for high speeds. Classification is done at the ingress 
only.
>
>  thanks,
>  Peter
>
>  >
>
>  ___
>  Lsr mailing list
>  Lsr@ietf.org
>  
https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsrdata=02*7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d867816541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637373152739865126sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3Dreserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcREUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>
>
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Good point!!




Juniper Business Use Only
From: Jeff Tantsura 
Sent: Thursday, October 1, 2020 2:08 AM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]

Hi Ron,

the readers would benefit if the draft would state that in order for the 
technology to work properly, there must be a contiguous set of connected 
routers that support it between the S/D, since lookup (route installed in 
context of the algo it is associated with) is done per hop.

Cheers,
Jeff
On Sep 30, 2020, 9:03 AM -0700, Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 wrote:
Hi Muthu,

Thanks for the review.

An interface can be associated with, at most, one Flexible Algorithm. Likewise, 
an IP address can be associated with, at most, one Flexible Algorithm.

I tried to express this in the text below, but probably didn't do a very good 
job. If you can think of a better way to say it, I would appreciate suggestions.

  Ron

Text from draft


Network operators configure multiple loopback interfaces on an egress
   node.  They can associate each loopback interface with:

   o  Zero or more IP addresses.

   o  Zero or one Flexible Algorithms.

   If an IP address and a Flexible Algorithm are associated with the
   same interface, they are also associated with one another.  An IP
   address MAY be associated with, at most, one interface.






Juniper Business Use Only
From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Sent: Wednesday, September 30, 2020 9:59 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]

A quick question:

   If an IP address and a Flexible Algorithm are associated with the

   same interface, they are also associated with one another.  An IP

   address MAY be associated with, at most, one interface.

If multiple IP addresses and multiple flexible algorithms are associated with a 
loopback interface, is each IP address associated with all flexible algorithms? 
What matters is the association b/w an IP address and a flexalgo, so the 
relationship should be defined in a direct way rather than each being 
associated with an interface, right?

Regards,
Muthu

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:

Please review and comment

   Ron



Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya mailto:pkane...@juniper.net>>; 
> Shraddha Hegde
> mailto:shrad...@juniper.net>>; Ron Bonica 
> mailto:rbon...@juniper.net>>; Rajesh M
> mailto:mraj...@juniper.net>>; William Britto A J 
> mailto:bwill...@juniper.net>>
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Name:   draft-bonica-lsr-ip-flexalgo
> Revision:   00
> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> Document date:  2020-09-29
> Group:  Individual Submission
> Pages:  14
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> Htmlized:   
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>
>
> Abstract:
>An IGP Flexible Algorithm computes a constraint-based path and maps
>that path to an identifier.  As currently

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Hi Tony,

You are correct in that a prefix can only be associated with one Flexalgo.

I will add some text about applications in the next version.

   Ron



Juniper Business Use Only

-Original Message-
From: Tony Li  On Behalf Of tony...@tony.li
Sent: Tuesday, September 29, 2020 10:05 AM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Ron,

This is nice. It makes it clear that constraint based path computation need not 
have MPLS overhead for those that don’t want it.

One thing that you don’t talk about is how this gets used, tho that may be 
blindingly obvious: you’ll need all nodes placing their prefixes in the 
RIB/FIB, where it will need to be selected over other path computation for the 
same prefixes.  This somewhat precludes the possibility of a given prefix being 
useful in multiple flex-algos.

More text on application would be most welcome, just to ensure that we’re on 
the same page.

Tony


> On Sep 29, 2020, at 6:37 AM, Ron Bonica 
>  wrote:
>
>
> Please review and comment
>
>   Ron
>
>
>
> Juniper Business Use Only
>
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Tuesday, September 29, 2020 9:36 AM
>> To: Parag Kaneriya ; Shraddha Hegde 
>> ; Ron Bonica ; Rajesh M 
>> ; William Britto A J 
>> Subject: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF 
>> repository.
>>
>> Name:   draft-bonica-lsr-ip-flexalgo
>> Revision:   00
>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
>> Document date:  2020-09-29
>> Group:  Individual Submission
>> Pages:  14
>> URL:
>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo
>> nica-lsr-
>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>> ft-
>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>> Htmlized:   
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>>
>>
>> Abstract:
>>   An IGP Flexible Algorithm computes a constraint-based path and maps
>>   that path to an identifier.  As currently defined, Flexalgo can only
>>   map the paths that it computes to Segment Routing (SR) identifiers.
>>   Therefore, Flexalgo cannot be deployed in the absence of SR.
>>
>>   This document extends Flexalgo, so that it can map the paths that it
>>   computes to IP addresses.  This allows Flexalgo to be deployed in any
>>   IP network, even in the absence of SR.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!RnM-z-O3leH_IIH06LxRzZKbRMQuuQcRs4g4RCiTbE0PleY70Sm2h3
> pFo42w7jA8$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Les,

Thanks for the review. All good catches.

We will address them all in the next draft version.

Ron



Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Wednesday, September 30, 2020 3:39 PM
To: Ron Bonica ; lsr@ietf.org
Subject: RE: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


Ron -

Interesting proposal.

A few mundane - but I think still important - comments.

New IS-IS TLVs


There is no need to have two TLVs for each address-family - one for MTID #0 and 
one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today is because MT (RFC 5120)  came along 
after TLV 135/236 had been defined/deployed.
Since you have a greenfield here you can simply have one TLV/AF and allow all 
MTIDs (including 0).

MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value.  
(I believe someone else pointed this out as well.) See RFC 5120.

You should specify that the new TLVs inherit the sub-TLV space defined in 
https://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml*isis-tlv-codepoints-135-235-236-237__;Iw!!NEt6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_C8qZvvh30w$

The U-bit
-

I appreciate that there is precedence for calling this the U-bit based on RFC 
5308 - but I would prefer that you call it the D-bit.
Regardless of name, it MUST be consistent with existing usage - meaning it is 
set when the prefix is leaked downwards. Currently your text says:

"U (1 bit): Set indicates up.  Clear indicates down."

This needs to be reversed.

Constraints
---

I think you need to speak to various constraints including (but not limited to):

1)Algorithm is limited to flex-algo values (128-255)

I don't understand why Section 6 (main part - not the sub-sections) is there. 
What relevance do non-flex-algos have to this draft??

I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm 
Sub-TLV".
Unless you are proposing to use this sub-TLV in ways not related to flex-algo - 
in which case I think you need to provide some explanation of the use case for 
this.

2)How to handle advertisement of same algo both in the new Algorithm sub-TLV 
and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy routers 
may understand SR Algorithm Sub-TLV but not the new one.

   Les



> -Original Message-
> From: Lsr  On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 6:38 AM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo- 00.txt
>
>
> Please review and comment
>
>Ron
>
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde 
> > ; Ron Bonica ; Rajesh M 
> > ; William Britto A J 
> > Subject: New Version Notification for 
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF 
> > repository.
> >
> > Name:   draft-bonica-lsr-ip-flexalgo
> > Revision:   00
> > Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:  Individual Submission
> > Pages:  14
> > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > aft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >An IGP Flexible Algorithm computes a constraint-based path and maps
> >that path to an identifier.  As currently defined, Flexalgo can only
> >map the paths that it computes to Segment Routing (SR) identifiers.
> >

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Hi Muthu,

Thanks for the review.

An interface can be associated with, at most, one Flexible Algorithm. Likewise, 
an IP address can be associated with, at most, one Flexible Algorithm.

I tried to express this in the text below, but probably didn't do a very good 
job. If you can think of a better way to say it, I would appreciate suggestions.

  Ron

Text from draft


Network operators configure multiple loopback interfaces on an egress
   node.  They can associate each loopback interface with:

   o  Zero or more IP addresses.

   o  Zero or one Flexible Algorithms.

   If an IP address and a Flexible Algorithm are associated with the
   same interface, they are also associated with one another.  An IP
   address MAY be associated with, at most, one interface.






Juniper Business Use Only
From: Muthu Arul Mozhi Perumal 
Sent: Wednesday, September 30, 2020 9:59 AM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]

A quick question:

   If an IP address and a Flexible Algorithm are associated with the

   same interface, they are also associated with one another.  An IP

   address MAY be associated with, at most, one interface.

If multiple IP addresses and multiple flexible algorithms are associated with a 
loopback interface, is each IP address associated with all flexible algorithms? 
What matters is the association b/w an IP address and a flexalgo, so the 
relationship should be defined in a direct way rather than each being 
associated with an interface, right?

Regards,
Muthu

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:

Please review and comment

   Ron



Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya mailto:pkane...@juniper.net>>; 
> Shraddha Hegde
> mailto:shrad...@juniper.net>>; Ron Bonica 
> mailto:rbon...@juniper.net>>; Rajesh M
> mailto:mraj...@juniper.net>>; William Britto A J 
> mailto:bwill...@juniper.net>>
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Name:   draft-bonica-lsr-ip-flexalgo
> Revision:   00
> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> Document date:  2020-09-29
> Group:  Individual Submission
> Pages:  14
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> Htmlized:   
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>
>
> Abstract:
>An IGP Flexible Algorithm computes a constraint-based path and maps
>that path to an identifier.  As currently defined, Flexalgo can only
>map the paths that it computes to Segment Routing (SR) identifiers.
>Therefore, Flexalgo cannot be deployed in the absence of SR.
>
>This document extends Flexalgo, so that it can map the paths that it
>computes to IP addresses.  This allows Flexalgo to be deployed in any
>IP network, even in the absence of SR.
>
>
>
>
> 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<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhG1kuR-O$>.
>
> The IETF Secretariat
>
__

[Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Ron Bonica]

Please review and comment

   Ron



Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya ; Shraddha Hegde
> ; Ron Bonica ; Rajesh M
> ; William Britto A J 
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-lsr-ip-flexalgo
> Revision:   00
> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> Document date:  2020-09-29
> Group:  Individual Submission
> Pages:  14
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> Htmlized:   https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> 
> 
> Abstract:
>An IGP Flexible Algorithm computes a constraint-based path and maps
>that path to an identifier.  As currently defined, Flexalgo can only
>map the paths that it computes to Segment Routing (SR) identifiers.
>Therefore, Flexalgo cannot be deployed in the absence of SR.
> 
>This document extends Flexalgo, so that it can map the paths that it
>computes to IP addresses.  This allows Flexalgo to be deployed in any
>IP network, even in the absence of SR.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Rtgdir last call review of draft-ietf-lsr-isis-invalid-tlv-02

[Ron Bonica via Datatracker]

Reviewer: Ron Bonica
Review result: Ready

This draft is well tought out and ready for publication


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-02.txt

[Ron Bonica]

FYI


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, March 23, 2020 2:34 PM
> To: Shraddha Hegde ; Ron Bonica
> ; Rajesh M ; Parag Kaneriya
> 
> Subject: New Version Notification for draft-bonica-lsr-crh-isis-extensions-
> 02.txt
> 
> 
> A new version of I-D, draft-bonica-lsr-crh-isis-extensions-02.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name: draft-bonica-lsr-crh-isis-extensions
> Revision: 02
> Title:IS-IS Extensions To Support The IPv6 Compressed Routing
> Header (CRH)
> Document date:2020-03-23
> Group:Individual Submission
> Pages:12
> URL:
> https://www.ietf.org/internet-drafts/draft-bonica-lsr-crh-isis-extensions-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/
> Htmlized:
> https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bonica-lsr-crh-isis-extensions
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-bonica-lsr-crh-isis-extensions-02
> 
> Abstract:
>Source nodes can use the IPv6 Compressed Routing Header (CRH) to
>steer packets through a specified path.  This document defines IS-IS
>extensions that support the CRH.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-00.txt

[Ron Bonica]

Robert,

I am preparing the overview document that you request as we speak. When it is 
ready, I will post it on the SPRING mailing list.

Ron

From: Robert Raszuk 
Sent: Tuesday, May 14, 2019 11:33 AM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-crh-isis-extensions-00.txt

Hi Ron,

Could you provide pointer to comparison of CRH vs SRH ? Do we really need to 
standardize both ? Is this going to help any practical deployments ?

Very honestly when I read this draft I needed to check date as I though we are 
back in 2002/2003 when CR-LDP was trying to compete with RSVP-TE :)

Cheers,
R.


On Tue, May 14, 2019 at 5:20 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Folks,

Please review and comment.

   Ron


Juniper Public

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Tuesday, May 14, 2019 11:14 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; Parag Kaneriya 
mailto:pkane...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>
Subject: New Version Notification for 
draft-bonica-lsr-crh-isis-extensions-00.txt


A new version of I-D, draft-bonica-lsr-crh-isis-extensions-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:   draft-bonica-lsr-crh-isis-extensions
Revision:   00
Title:  IS-IS Extensions To Support The IPv6 Compressed Routing Header 
(CRH)
Document date:  2019-05-14
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/id/draft-bonica-lsr-crh-isis-extensions-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dbonica-2Dlsr-2Dcrh-2Disis-2Dextensions-2D00.txt=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=i86HMTCDqGMg7PIzEvTtjI0PwfYfQDPX5M1eBAu0e4o=BB-2iAR25VaEj8OAou1-5MGPcrSBIeugvs265LdbOhs=>

Status: 
https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf..org_doc_draft-2Dbonica-2Dlsr-2Dcrh-2Disis-2Dextensions_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=i86HMTCDqGMg7PIzEvTtjI0PwfYfQDPX5M1eBAu0e4o=FRImwMd_gVR5YuQTxYAiBeqKQpyDvei3J9B_AlEeh50=>

Htmlized: 
https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dlsr-2Dcrh-2Disis-2Dextensions-2D00=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=i86HMTCDqGMg7PIzEvTtjI0PwfYfQDPX5M1eBAu0e4o=b_e5p1YgVxtxFK0Zm96A3bpOkqlEmJZFQB9qAyF1B6o=>


Abstract:
   Source nodes can use the IPv6 Compressed Routing Header (CRH) to
   steer packets through a specified path.  This document defines IS-IS
   extensions that support the CRH.




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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=i86HMTCDqGMg7PIzEvTtjI0PwfYfQDPX5M1eBAu0e4o=_IIr_-sqyyrVOgTC3GsQjEW6uYkop1X9qtqS-OrZ2JE=>.

The IETF Secretariat
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=i86HMTCDqGMg7PIzEvTtjI0PwfYfQDPX5M1eBAu0e4o=LBEiLZz1Q6vYgcMjLMQQcuVwVzVUvHljXWgKpptzrBc=>


Juniper Internal
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-00.txt

[Ron Bonica]

Folks,

Please review and comment.

   Ron


Juniper Public

-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, May 14, 2019 11:14 AM
To: Ron Bonica ; Shraddha Hegde ; 
Parag Kaneriya ; Rajesh M 
Subject: New Version Notification for 
draft-bonica-lsr-crh-isis-extensions-00.txt


A new version of I-D, draft-bonica-lsr-crh-isis-extensions-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:   draft-bonica-lsr-crh-isis-extensions
Revision:   00
Title:  IS-IS Extensions To Support The IPv6 Compressed Routing Header 
(CRH)
Document date:  2019-05-14
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/id/draft-bonica-lsr-crh-isis-extensions-00.txt

Status: https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/

Htmlized: https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-00


Abstract:
   Source nodes can use the IPv6 Compressed Routing Header (CRH) to
   steer packets through a specified path.  This document defines IS-IS
   extensions that support the CRH.


  


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.

The IETF Secretariat
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr