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

2020-10-20 Thread Peter Psenak

Bruno,

On 20/10/2020 14:47, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

please see inline:



On 20/10/2020 11:43, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS

and

IP flexalgo in the same network.


>From a protocol standpoint, I think that the functionality could be

equally

met by advertising SR-MPLS SID as per RFC 8667 but using a label 3

(implicit

null) to instruct the LER/LSR to not use a label in the forwarding plane.

(while

still advertising a label in the control plane because we have to).

does not work,


I could provide more explanations, but reading your email, it seems to me

that you understood the proposal.

So it seems to me that the opinion that you really meant is: it works but it

would be an nasty hack.


Regarding "nasty hack" it could be interesting to have a normative

definition. This could prove useful in some other contexts.

BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link

in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label
in the NLRI...

max-metric does not solve the problem, as you would need a prefix metric
for non 0 algo anyway.


To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.


Coming back to technical comments, note that creating yet another TLV to

carry IP prefix also brings questions that the draft does not answer or even
raise.

- What about the sub-TLVs? Are they shared with the existing registry for

prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
(we would have two algo fields, two ways to signal SIDs...)

yes, these are details that needs to be addressed, but should not be a
problem. Look at locator TLV in SRv6, very similar concept here.


- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix

Reachability TLV" is essentially the same than the "SRv6 Locator TLV".

- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a

Routing Algo)? Duplication means more spec, more code, more features to
implement, more error and bugs. (and it did not took long: the draft defines
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.

well, locator is a construct that is specific to SRv6. Sure you can
advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
and achieve the same thing - I have already mentioned that in one of my
responses, but that is again ugly.


So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the same 
information and to provide the same functionality.

  

- What is the functional different between FlexAlgo for SRv6 and

FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
the IPv6 FIB in the router.

they are functionally the same.


Good to agree on this.
  

I believe that having a clean encoding is preferable in a long run.


What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.


One
can not advertise a prefix as SRv6 locator as well as IP flex-algo
prefix (that would be an error), so duplication of data is not an
issues.


So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.


I don't see that error an issue.




And having a dedicated TLV for each is better from both
deployment and implementation perspective.


I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.


not really, I prefer clean encoding rather the overloading things as we 
extend protocol.



I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).


I don't agree. If we keep things clean we would not allow "vendor 
implementing TLV A while another vendor implementing TLV B".


Anyway, it's for the WG to decide what 

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

2020-10-20 Thread bruno.decraene
Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> please see inline:
> 
> 
> 
> On 20/10/2020 11:43, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Bruno,
> >>
> >> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> >>> Ron, all,
> >>>
> >>> >From a use case standpoint, I have a use case for having both SR-MPLS
> and
> >> IP flexalgo in the same network.
> >>>
> >>> >From a protocol standpoint, I think that the functionality could be
> equally
> >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3
> (implicit
> >> null) to instruct the LER/LSR to not use a label in the forwarding plane.
> (while
> >> still advertising a label in the control plane because we have to).
> >>
> >> does not work,
> >
> > I could provide more explanations, but reading your email, it seems to me
> that you understood the proposal.
> > So it seems to me that the opinion that you really meant is: it works but it
> would be an nasty hack.
> >
> > Regarding "nasty hack" it could be interesting to have a normative
> definition. This could prove useful in some other contexts.
> > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the 
> > link
> in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
> label
> in the NLRI...
> 
> max-metric does not solve the problem, as you would need a prefix metric
> for non 0 algo anyway.

To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.

> > Coming back to technical comments, note that creating yet another TLV to
> carry IP prefix also brings questions that the draft does not answer or even
> raise.
> > - What about the sub-TLVs? Are they shared with the existing registry for
> prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
> (we would have two algo fields, two ways to signal SIDs...)
> 
> yes, these are details that needs to be addressed, but should not be a
> problem. Look at locator TLV in SRv6, very similar concept here.
> 
> > - for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix
> Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
> > - Only the naming and the ordering of the fields are different.
> > - Why do we need two TLVs to advertise the same thing (essentially a
> Routing Algo)? Duplication means more spec, more code, more features to
> implement, more error and bugs. (and it did not took long: the draft defines
> the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
> 
> well, locator is a construct that is specific to SRv6. Sure you can
> advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
> and achieve the same thing - I have already mentioned that in one of my
> responses, but that is again ugly.

So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the 
same information and to provide the same functionality.

 
> > - What is the functional different between FlexAlgo for SRv6 and
> FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
> the IPv6 FIB in the router.
> 
> they are functionally the same.

Good to agree on this.
 
> I believe that having a clean encoding is preferable in a long run.

What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.

> One
> can not advertise a prefix as SRv6 locator as well as IP flex-algo
> prefix (that would be an error), so duplication of data is not an
> issues.

So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.

> And having a dedicated TLV for each is better from both
> deployment and implementation perspective.

I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.
I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).

Thanks,
--Bruno
 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > Thanks,
> > Bruno
> >
> >> as it does not allow you to associate the prefix with
> >> Flex-algo without advertising the 

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

2020-10-20 Thread Peter Psenak

Bruno,

please see inline:



On 20/10/2020 11:43, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and

IP flexalgo in the same network.


>From a protocol standpoint, I think that the functionality could be equally

met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
null) to instruct the LER/LSR to not use a label in the forwarding plane. (while
still advertising a label in the control plane because we have to).

does not work,


I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts.
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP 
SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI...


max-metric does not solve the problem, as you would need a prefix metric 
for non 0 algo anyway.



Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)


yes, these are details that needs to be addressed, but should not be a 
problem. Look at locator TLV in SRv6, very similar concept here.



- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" 
is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.


well, locator is a construct that is specific to SRv6. Sure you can 
advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs 
and achieve the same thing - I have already mentioned that in one of my 
responses, but that is again ugly.



- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.


they are functionally the same.

I believe that having a clean encoding is preferable in a long run. One 
can not advertise a prefix as SRv6 locator as well as IP flex-algo 
prefix (that would be an error), so duplication of data is not an 
issues. And having a dedicated TLV for each is better from both 
deployment and implementation perspective.


thanks,
Peter






Thanks,
Bruno


as it does not allow you to associate the prefix with
Flex-algo without advertising the reachability in algo 0. Making the
prefix reachability in default algo conditional based on the presence of
the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.

Not to mention that advertising a Prefix SID in pure IP network would be
ugly.

thanks,
Peter




I feel that this would be less change in the protocol (no new tlv), a good fit

for network requiring both MPLS and IP flex algo, and would not require
implementations/network operator to duplicate the "prefix sub-TLV" [1] on
both advertisements (IP based and SR-MPLS based).


That would still requires a protocol extension/STD track RFC as RFC 8667

does not allow for this. That would still require change to implementations as
only the signalling is different while the feature/behavior is the same (i.e. no
magic).


Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,

MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Tuesday, September 29, 2020 3:38 PM
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

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

2020-10-20 Thread bruno.decraene
Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> > Ron, all,
> >
> >>From a use case standpoint, I have a use case for having both SR-MPLS and
> IP flexalgo in the same network.
> >
> >>From a protocol standpoint, I think that the functionality could be equally
> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
> null) to instruct the LER/LSR to not use a label in the forwarding plane. 
> (while
> still advertising a label in the control plane because we have to).
> 
> does not work,

I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts. 
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link 
in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label in the NLRI...


Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)
- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix 
Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.

Thanks,
Bruno

> as it does not allow you to associate the prefix with
> Flex-algo without advertising the reachability in algo 0. Making the
> prefix reachability in default algo conditional based on the presence of
> the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.
> 
> Not to mention that advertising a Prefix SID in pure IP network would be
> ugly.
> 
> thanks,
> Peter
> 
> 
> 
> > I feel that this would be less change in the protocol (no new tlv), a good 
> > fit
> for network requiring both MPLS and IP flex algo, and would not require
> implementations/network operator to duplicate the "prefix sub-TLV" [1] on
> both advertisements (IP based and SR-MPLS based).
> >
> > That would still requires a protocol extension/STD track RFC as RFC 8667
> does not allow for this. That would still require change to implementations as
> only the signalling is different while the feature/behavior is the same (i.e. 
> no
> magic).
> >
> > Regards,
> > --Bruno
> >
> > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,
> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"
> >
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Tuesday, September 29, 2020 3:38 PM
> >> 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:
> >>>
> 

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

2020-10-19 Thread Peter Psenak

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,


From a use case standpoint, I have a use case for having both SR-MPLS and IP 
flexalgo in the same network.



From a protocol standpoint, I think that the functionality could be equally met 
by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) 
to instruct the LER/LSR to not use a label in the forwarding plane. (while 
still advertising a label in the control plane because we have to).


does not work, as it does not allow you to associate the prefix with
Flex-algo without advertising the reachability in algo 0. Making the 
prefix reachability in default algo conditional based on the presence of 
the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.


Not to mention that advertising a Prefix SID in pure IP network would be 
ugly.


thanks,
Peter




I feel that this would be less change in the protocol (no new tlv), a good fit for 
network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. 
Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"



-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Tuesday, September 29, 2020 3:38 PM
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/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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is 

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

2020-10-19 Thread bruno.decraene
Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and IP 
>flexalgo in the same network.

>From a protocol standpoint, I think that the functionality could be equally 
>met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit 
>null) to instruct the LER/LSR to not use a label in the forwarding plane. 
>(while still advertising a label in the control plane because we have to).
I feel that this would be less change in the protocol (no new tlv), a good fit 
for network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT 
IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 3:38 PM
> 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/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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
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

2020-10-01 Thread 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

2020-10-01 Thread 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] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

2020-10-01 Thread Peter Psenak
     need to
 >      > support the new functionality while rest of the network
does not
 >     need to
 >      > be even aware about it.
 >
 >     above is not really true.
 >
 >     Algo participation needs to be signaled, one way or the
other. It's
 >     done
 >     for SR as well. There is no need for all routers to understand
 >     flex-algo, as only those that participate (and as a result also
 >     understand it) will be used during the flex-algo path
computation and
 >     consequently flex-algo specific forwarding. This applies to
 >     flex-algo in
 >     general, regardless of the data plane being used.
 >
 >     thanks,
 >     Peter
 >
 >
 >      >
 >      > Many thx,
 >      > R.
 >      >
 >      >
 >      > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo
mailto:huzh...@huawei.com>
 >     <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>
 >      > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>
<mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>>> wrote:
 >      >
 >      >     Hi Joel:
 >      >
 >      >          For details about the method defined in RFC 6550. It
 >     uses the
 >      >     HBH option to carry the RPLInstaceID. The RPLInstaceID and
 >      >     FlexAlgoID are similar.
 >      >
 >      >     Thanks
 >      >
 >      >     Zhibo
 >      >
 >      >     -Original Message-
 >      >     From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>
 >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>
 >      >     <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>>>]
 >     On Behalf Of Joel M. Halpern
 >      >     Sent: Wednesday, September 30, 2020 12:05 PM
 >      >     Cc: lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>> <mailto:lsr@ietf.org
<mailto:lsr@ietf.org>
 >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
 >      >     Subject: Re: [Lsr] New Version Notification for
 >      >     draft-bonica-lsr-ip-flexalgo-00.txt
 >      >
 >      >     I am missing something in this discussion of multiple
algorithms.
 >      >
 >      >     My understanding of flex-algo whether for MPLS, SRv6,
SRH, or
 >     IPv6,
 >      >     is that you need to associated a forwarding label
(e.g. MPLS
 >     label
 >      >     or IPv6
 >      >     address) with a specific algorithm so that you can compute
 >     the next
 >      >     hope for the forwarding label using the proper algorithm.
 >     Then when
 >      >     a packet arrives, it is simply forwarded according to the
 >     forwarding
 >      >     table (e.g.
 >      >     FIB, LIB, ..)
 >      >
 >      >     If that is so, then I do not understand how a given
prefix can be
 >      >     safely associated with more than one algorithm.  I
could imagine
 >      >     doing several calculations according to different
 >     algorithms.  But
 >      >     how do you decide which one applies to the packet?  As
far as I
 >      >     know, flex-algo does not look at the QoS/CoS/ToS bits.
 >      >
 >      >     Yours,
 >      >     Joel
 >      >
 >      >     PS: I will admit that it took until  an operator
described some
 >      >     "interesting" constraints before I understood why one
would
 >     even do
 >      >     this.
 >      >
 >      >     On 9/29/2020 11:50 PM, Huzhibo wrote:
 >      >      > Hi.
 >      >      >
 >      >      > Associating multiple algorithms with a given prefix
is an
 >      >     interesting topic, and I think this can simplify the
 >     complexity of
 >      >     FlexAlgo. I wonder if the author would consider using
cases with
 >      >     multiple algorithms with a given prefix.
 >      >      >
 >      >      > Thanks
 >      >      >
 >      >      > ZHibo
 >      >      >
 >      >      > -Original Message-
 >      >      > From: Lsr [mailto:

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

2020-09-30 Thread Les Ginsberg (ginsberg)
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://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237
 

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/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 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

2020-09-30 Thread Robert Raszuk
; >
> >  >
> >  > Many thx,
> >  > R.
> >  >
> >  >
> >  > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  > <mailto:huzh...@huawei.com>
> >  > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>> wrote:
> >  >
> >  > Hi Joel:
> >  >
> >  >  For details about the method defined in RFC 6550. It
> > uses the
> >  >     HBH option to carry the RPLInstaceID. The RPLInstaceID and
> >  > FlexAlgoID are similar.
> >  >
> >  > Thanks
> >  >
> >  > Zhibo
> >  >
> >  > -Original Message-
> >  > From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>
> >  > <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>]
> > On Behalf Of Joel M. Halpern
> >  > Sent: Wednesday, September 30, 2020 12:05 PM
> >  > Cc: lsr@ietf.org <mailto:lsr@ietf.org> <mailto:lsr@ietf.org
> > <mailto:lsr@ietf.org>>
> >  > Subject: Re: [Lsr] New Version Notification for
> >  > draft-bonica-lsr-ip-flexalgo-00.txt
> >  >
> >  > I am missing something in this discussion of multiple
> algorithms.
> >  >
> >  > My understanding of flex-algo whether for MPLS, SRv6, SRH, or
> > IPv6,
> >  > is that you need to associated a forwarding label (e.g. MPLS
> > label
> >  > or IPv6
> >  > address) with a specific algorithm so that you can compute
> > the next
> >  > hope for the forwarding label using the proper algorithm.
> > Then when
> >  > a packet arrives, it is simply forwarded according to the
> > forwarding
> >  > table (e.g.
> >  > FIB, LIB, ..)
> >  >
> >  > If that is so, then I do not understand how a given prefix
> can be
> >  > safely associated with more than one algorithm.  I could
> imagine
> >  > doing several calculations according to different
> > algorithms.  But
> >  > how do you decide which one applies to the packet?  As far as
> I
> >  > know, flex-algo does not look at the QoS/CoS/ToS bits.
> >  >
> >  > Yours,
> >  > Joel
> >  >
> >  > PS: I will admit that it took until  an operator described
> some
> >  > "interesting" constraints before I understood why one would
> > even do
> >  > this.
> >  >
> >  > On 9/29/2020 11:50 PM, Huzhibo wrote:
> >      >  > Hi.
> >  >  >
> >      >  > Associating multiple algorithms with a given prefix is an
> >  > interesting topic, and I think this can simplify the
> > complexity of
> >  > FlexAlgo. I wonder if the author would consider using cases
> with
> >  > multiple algorithms with a given prefix.
> >  >  >
> >  >  > Thanks
> >  >  >
> >  >  > ZHibo
> >  >  >
> >  >  > -Original Message-
> >  >  > From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>
> >  > <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>]
> > On Behalf Of tony...@tony.li <mailto:tony...@tony.li>
> >  > <mailto:tony...@tony.li <mailto:tony...@tony.li>>
> >  >  > Sent: Tuesday, September 29, 2020 10:05 PM
> >  >  > To: Ron Bonica  > <mailto:40juniper@dmarc.ietf.org>
> >  > <mailto:40juniper@dmarc.ietf.org
> > <mailto:40juniper@dmarc.ietf.org>>>
> >  >  > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> > <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
> >  >  > Subject: Re: [Lsr] New Version Notification for
> >  >  > draft-bonica-lsr-ip-flexalgo-00.txt
> >  >  >
> >  >  >
> >  >  > 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.
> >  >

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

2020-09-30 Thread Peter Psenak

Robert,

On 30/09/2020 16:28, Robert Raszuk wrote:

Peter,

Let's see if we are talking about the same thing ...

Take SRv6 as example ... You can run flex algorithm only on selected 
segment endpoints as you do encap and dst rewrite. So rest of the 
network (P/transit routers) do not need to have a clue about any 
flex-algo other then plain old SPF.


if all transit nodes do not participate/understand flex-algo, you will 
not be able to route the traffic between the segment endpoints based on 
the flex-algo, in other words algo specific locators will not be reachable.




Now in Ron's case where there is no encap and you are applying flex-algo 
to naked packets don't you think there is a difference and a bit of 
deployment difficulty to make it work ?


it is the same as with SRv6 locator - prefix associated with algorithm, 
with some additional SRv6 data. From the flex-algo calculation and 
forwarding perspective there is no difference.




So assume one P node will not support it. This is native IP switching so 
BGP advertises routes with new flex-algo next hop. If that next hop is 
unreachable as signalling to that flex algo loopback was not understood 
by P (new signalling extension) packets will be dropped.


such P node would never ever be in the flex-algo forwarding path for 
prefix associated with flex-algo. We are talking underlay here, not BGP. 
BGP service allocates the SRV6 SID from the algo specific locator in 
case of SRv6. It can pick the NH as algo specific prefix I assume and 
the rest is the same.




But what if that next hop would happen to be covered by some aggregate 
route not subject perhaps to intended IP TE ?


aggregation needs to be algo aware for it to work.

thanks,
Peter




Cheers,
R.



On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote:


Hi Robert,

On 30/09/2020 09:28, Robert Raszuk wrote:
 > Hi,
 >
 >  > It uses the HBH option
 >
 > Currently Ron's proposal seems to work well for both IPv4 and IPv6
 > addresses. I hope this discussion will not try to derail it to
IPv6 only
 > track.
 >
 > I see no issue with loopback to flexible algorithm mapping in 1:1
fashion.
 >
 > I do however see some issues in deploying such technology as it will
 > only work well if *all* nodes in the network support this new
 > functionality. In contrast in SR world or control plane based TE I
 > proposed or any encapsulation based proposal only anchor nodes
need to
 > support the new functionality while rest of the network does not
need to
 > be even aware about it.

above is not really true.

Algo participation needs to be signaled, one way or the other. It's
done
for SR as well. There is no need for all routers to understand
flex-algo, as only those that participate (and as a result also
understand it) will be used during the flex-algo path computation and
consequently flex-algo specific forwarding. This applies to
flex-algo in
general, regardless of the data plane being used.

thanks,
Peter


 >
 > Many thx,
 > R.
 >
 >
 > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo mailto:huzh...@huawei.com>
 > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>> wrote:
 >
 >     Hi Joel:
 >
 >          For details about the method defined in RFC 6550. It
uses the
 >     HBH option to carry the RPLInstaceID. The RPLInstaceID and
 >     FlexAlgoID are similar.
 >
 >     Thanks
 >
 >     Zhibo
 >
 >     -Original Message-
 >     From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>
 >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>]
On Behalf Of Joel M. Halpern
 >     Sent: Wednesday, September 30, 2020 12:05 PM
 >     Cc: lsr@ietf.org <mailto:lsr@ietf.org> <mailto:lsr@ietf.org
<mailto:lsr@ietf.org>>
 >     Subject: Re: [Lsr] New Version Notification for
 >     draft-bonica-lsr-ip-flexalgo-00.txt
 >
 >     I am missing something in this discussion of multiple algorithms.
 >
 >     My understanding of flex-algo whether for MPLS, SRv6, SRH, or
IPv6,
 >     is that you need to associated a forwarding label (e.g. MPLS
label
 >     or IPv6
 >     address) with a specific algorithm so that you can compute
the next
 >     hope for the forwarding label using the proper algorithm. 
Then when

 >     a packet arrives, it is simply forwarded according to the
forwarding
 >     table (e.g.
 >     FIB, LIB, ..)
 >
 >     If that is so, then I do not understand how a given prefix can be
 >     safely associated

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

2020-09-30 Thread Dongjie (Jimmy)
Hi,

While it is possible to define algorithm-specific IP reachability TLVs to 
advertise IP Prefixes associated with different algorithms, this would 
introduce several new IS-IS top TLVs. One quick question is: can similar 
function be provided with extensions to existing IP reachability TLVs and MT IP 
reachability TLVs, instead of defining top TLVs for MT, Flex-Algo, and the 
combination of Flex-Algo and MT respectively?

And one nit in the encoding: the length of MT-ID in IS-IS should be 12 bits.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, September 30, 2020 3:28 PM
To: Huzhibo mailto:huzh...@huawei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Joel M. Halpern 
mailto:j...@joelhalpern.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

Hi,

> It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6 addresses. I 
hope this discussion will not try to derail it to IPv6 only track.

I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will only work 
well if *all* nodes in the network support this new functionality. In contrast 
in SR world or control plane based TE I proposed or any encapsulation based 
proposal only anchor nodes need to support the new functionality while rest of 
the network does not need to be even aware about it.

Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo 
mailto:huzh...@huawei.com>> wrote:
Hi Joel:

For details about the method defined in RFC 6550. It uses the HBH option to 
carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar.

Thanks

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you 
need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope for 
the forwarding label using the proper algorithm.  Then when a packet arrives, 
it is simply forwarded according to the forwarding table (e.g.
FIB, LIB, ..)

If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide which 
one applies to the packet?  As far as I know, flex-algo does not look at the 
QoS/CoS/ToS bits.

Yours,
Joel

PS: I will admit that it took until  an operator described some "interesting" 
constraints before I understood why one would even do this.

On 9/29/2020 11:50 PM, Huzhibo wrote:
> Hi.
>
> Associating multiple algorithms with a given prefix is an interesting topic, 
> and I think this can simplify the complexity of FlexAlgo. I wonder if the 
> author would consider using cases with multiple algorithms with a given 
> prefix.
>
> Thanks
>
> ZHibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On 
> Behalf Of tony...@tony.li<mailto:tony...@tony.li>
> Sent: Tuesday, September 29, 2020 10:05 PM
> To: Ron Bonica 
> mailto:40juniper....@dmarc.ietf.org>>
> Cc: lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
>
> 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 
>> 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:3

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

2020-09-30 Thread Robert Raszuk
Peter,

Let's see if we are talking about the same thing ...

Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the network
(P/transit routers) do not need to have a clue about any flex-algo
other then plain old SPF.

Now in Ron's case where there is no encap and you are applying flex-algo to
naked packets don't you think there is a difference and a bit of deployment
difficulty to make it work ?

So assume one P node will not support it. This is native IP switching so
BGP advertises routes with new flex-algo next hop. If that next hop is
unreachable as signalling to that flex algo loopback was not understood by
P (new signalling extension) packets will be dropped.

But what if that next hop would happen to be covered by some aggregate
route not subject perhaps to intended IP TE ?

Cheers,
R.



On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak  wrote:

> Hi Robert,
>
> On 30/09/2020 09:28, Robert Raszuk wrote:
> > Hi,
> >
> >  > It uses the HBH option
> >
> > Currently Ron's proposal seems to work well for both IPv4 and IPv6
> > addresses. I hope this discussion will not try to derail it to IPv6 only
> > track.
> >
> > I see no issue with loopback to flexible algorithm mapping in 1:1
> fashion.
> >
> > I do however see some issues in deploying such technology as it will
> > only work well if *all* nodes in the network support this new
> > functionality. In contrast in SR world or control plane based TE I
> > proposed or any encapsulation based proposal only anchor nodes need to
> > support the new functionality while rest of the network does not need to
> > be even aware about it.
>
> above is not really true.
>
> Algo participation needs to be signaled, one way or the other. It's done
> for SR as well. There is no need for all routers to understand
> flex-algo, as only those that participate (and as a result also
> understand it) will be used during the flex-algo path computation and
> consequently flex-algo specific forwarding. This applies to flex-algo in
> general, regardless of the data plane being used.
>
> thanks,
> Peter
>
>
> >
> > Many thx,
> > R.
> >
> >
> > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  > <mailto:huzh...@huawei.com>> wrote:
> >
> > Hi Joel:
> >
> >  For details about the method defined in RFC 6550. It uses the
> > HBH option to carry the RPLInstaceID. The RPLInstaceID and
> > FlexAlgoID are similar.
> >
> > Thanks
> >
> > Zhibo
> >
> >     -Original Message-
> >     From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern
> > Sent: Wednesday, September 30, 2020 12:05 PM
> > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > I am missing something in this discussion of multiple algorithms.
> >
> > My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6,
> > is that you need to associated a forwarding label (e.g. MPLS label
> > or IPv6
> > address) with a specific algorithm so that you can compute the next
> > hope for the forwarding label using the proper algorithm.  Then when
> > a packet arrives, it is simply forwarded according to the forwarding
> > table (e.g.
> > FIB, LIB, ..)
> >
> > If that is so, then I do not understand how a given prefix can be
> > safely associated with more than one algorithm.  I could imagine
> > doing several calculations according to different algorithms.  But
> > how do you decide which one applies to the packet?  As far as I
> > know, flex-algo does not look at the QoS/CoS/ToS bits.
> >
> > Yours,
> > Joel
> >
> > PS: I will admit that it took until  an operator described some
> > "interesting" constraints before I understood why one would even do
> > this.
> >
> > On 9/29/2020 11:50 PM, Huzhibo wrote:
> >  > Hi.
> >  >
> >  > Associating multiple algorithms with a given prefix is an
> > interesting topic, and I think this can simplify the complexity of
> > FlexAlgo. I wonder if the author would consider using cases with
> > multiple algorithms with a given prefix.
> >  >
> >  > Thanks
> >  >
> >  > ZHibo
> >  >
> >  > -Original Message-
> >  > Fro

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

2020-09-30 Thread Peter Psenak

Hi Robert,

On 30/09/2020 09:28, Robert Raszuk wrote:

Hi,

 > It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6 
addresses. I hope this discussion will not try to derail it to IPv6 only 
track.


I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will 
only work well if *all* nodes in the network support this new 
functionality. In contrast in SR world or control plane based TE I 
proposed or any encapsulation based proposal only anchor nodes need to 
support the new functionality while rest of the network does not need to 
be even aware about it.


above is not really true.

Algo participation needs to be signaled, one way or the other. It's done 
for SR as well. There is no need for all routers to understand 
flex-algo, as only those that participate (and as a result also 
understand it) will be used during the flex-algo path computation and 
consequently flex-algo specific forwarding. This applies to flex-algo in 
general, regardless of the data plane being used.


thanks,
Peter




Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo <mailto:huzh...@huawei.com>> wrote:


Hi Joel:

     For details about the method defined in RFC 6550. It uses the
HBH option to carry the RPLInstaceID. The RPLInstaceID and
FlexAlgoID are similar.

Thanks

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org <mailto:lsr@ietf.org>
    Subject: Re: [Lsr] New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6,
is that you need to associated a forwarding label (e.g. MPLS label
or IPv6
address) with a specific algorithm so that you can compute the next
hope for the forwarding label using the proper algorithm.  Then when
a packet arrives, it is simply forwarded according to the forwarding
table (e.g.
FIB, LIB, ..)

If that is so, then I do not understand how a given prefix can be
safely associated with more than one algorithm.  I could imagine
doing several calculations according to different algorithms.  But
how do you decide which one applies to the packet?  As far as I
know, flex-algo does not look at the QoS/CoS/ToS bits.

Yours,
Joel

PS: I will admit that it took until  an operator described some
"interesting" constraints before I understood why one would even do
this.

On 9/29/2020 11:50 PM, Huzhibo wrote:
 > Hi.
 >
 > Associating multiple algorithms with a given prefix is an
interesting topic, and I think this can simplify the complexity of
FlexAlgo. I wonder if the author would consider using cases with
multiple algorithms with a given prefix.
 >
 > Thanks
 >
 > ZHibo
 >
 > -Original Message-
 > From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of tony...@tony.li
<mailto:tony...@tony.li>
 > Sent: Tuesday, September 29, 2020 10:05 PM
 > To: Ron Bonica mailto:40juniper....@dmarc.ietf.org>>
 > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
 > Subject: Re: [Lsr] New Version Notification for
 > draft-bonica-lsr-ip-flexalgo-00.txt
 >
 >
 > 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
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

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

2020-09-30 Thread Peter Psenak

Hi Joel,

On 30/09/2020 06:04, Joel M. Halpern wrote:

I am missing something in this discussion of multiple algorithms.


not really.



My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
that you need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope
for the forwarding label using the proper algorithm.  Then when a packet
arrives, it is simply forwarded according to the forwarding table (e.g.
FIB, LIB, ..)


right.

For SR MPLS, the flex-algo forwarding is associated with the algo 
specific label that is derived from the algo specific SID. That unique 
algo specific label allows the traffic for the same prefix to be 
forwarded using many algorithms by simply using the right MPLS label.


For SRv6, the SRv6 Locator is associated with a single Algorithm.

The proposal here is to associate the prefix with the unique flex-algo 
only and use that association on all routers. This is similar to SRv6 
locators.




If that is so, then I do not understand how a given prefix can be safely
associated with more than one algorithm.  I could imagine doing several
calculations according to different algorithms.  But how do you decide
which one applies to the packet?  As far as I know, flex-algo does not
look at the QoS/CoS/ToS bits.


absolutely not. Doing classification of the data traffic at each hop 
does not work. It has been attempted in the past, but without much success.


thanks,
Peter




Yours,
Joel

PS: I will admit that it took until  an operator described some
"interesting" constraints before I understood why one would even do this.

On 9/29/2020 11:50 PM, Huzhibo wrote:

Hi.

Associating multiple algorithms with a given prefix is an interesting topic, 
and I think this can simplify the complexity of FlexAlgo. I wonder if the 
author would consider using cases with multiple algorithms with a given prefix.

Thanks

ZHibo

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


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.

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

2020-09-30 Thread Robert Raszuk
Hi,

> It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.

I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will only
work well if *all* nodes in the network support this new functionality. In
contrast in SR world or control plane based TE I proposed or any
encapsulation based proposal only anchor nodes need to support the new
functionality while rest of the network does not need to be even aware
about it.

Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  wrote:

> Hi Joel:
>
> For details about the method defined in RFC 6550. It uses the HBH
> option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are
> similar.
>
> Thanks
>
> Zhibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Wednesday, September 30, 2020 12:05 PM
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> I am missing something in this discussion of multiple algorithms.
>
> My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
> that you need to associated a forwarding label (e.g. MPLS label or IPv6
> address) with a specific algorithm so that you can compute the next hope
> for the forwarding label using the proper algorithm.  Then when a packet
> arrives, it is simply forwarded according to the forwarding table (e.g.
> FIB, LIB, ..)
>
> If that is so, then I do not understand how a given prefix can be safely
> associated with more than one algorithm.  I could imagine doing several
> calculations according to different algorithms.  But how do you decide
> which one applies to the packet?  As far as I know, flex-algo does not look
> at the QoS/CoS/ToS bits.
>
> Yours,
> Joel
>
> PS: I will admit that it took until  an operator described some
> "interesting" constraints before I understood why one would even do this.
>
> On 9/29/2020 11:50 PM, Huzhibo wrote:
> > Hi.
> >
> > Associating multiple algorithms with a given prefix is an interesting
> topic, and I think this can simplify the complexity of FlexAlgo. I wonder
> if the author would consider using cases with multiple algorithms with a
> given prefix.
> >
> > Thanks
> >
> > ZHibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> > Sent: Tuesday, September 29, 2020 10:05 PM
> > To: Ron Bonica 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> >
> > 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  40juniper@dmarc.ietf.org> 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
> 

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

2020-09-29 Thread Huzhibo
Hi Joel:

For details about the method defined in RFC 6550. It uses the HBH option to 
carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar.

Thanks

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you 
need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope for 
the forwarding label using the proper algorithm.  Then when a packet arrives, 
it is simply forwarded according to the forwarding table (e.g. 
FIB, LIB, ..)

If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide which 
one applies to the packet?  As far as I know, flex-algo does not look at the 
QoS/CoS/ToS bits.

Yours,
Joel

PS: I will admit that it took until  an operator described some "interesting" 
constraints before I understood why one would even do this.

On 9/29/2020 11:50 PM, Huzhibo wrote:
> Hi.
> 
> Associating multiple algorithms with a given prefix is an interesting topic, 
> and I think this can simplify the complexity of FlexAlgo. I wonder if the 
> author would consider using cases with multiple algorithms with a given 
> prefix.
> 
> Thanks
> 
> ZHibo
> 
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> Sent: Tuesday, September 29, 2020 10:05 PM
> To: Ron Bonica 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> 
> 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-b
>>> o
>>> nica-lsr-
>>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>>> Htmlized:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>> a
>>> 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

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

2020-09-29 Thread Joel M. Halpern

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is 
that you need to associated a forwarding label (e.g. MPLS label or IPv6 
address) with a specific algorithm so that you can compute the next hope 
for the forwarding label using the proper algorithm.  Then when a packet 
arrives, it is simply forwarded according to the forwarding table (e.g. 
FIB, LIB, ..)


If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide 
which one applies to the packet?  As far as I know, flex-algo does not 
look at the QoS/CoS/ToS bits.


Yours,
Joel

PS: I will admit that it took until  an operator described some 
"interesting" constraints before I understood why one would even do this.


On 9/29/2020 11:50 PM, Huzhibo wrote:

Hi.

Associating multiple algorithms with a given prefix is an interesting topic, 
and I think this can simplify the complexity of FlexAlgo. I wonder if the 
author would consider using cases with multiple algorithms with a given prefix.

Thanks

ZHibo

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


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://www.ietf.org/mailman/listinfo/lsr


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



___
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

2020-09-29 Thread Huzhibo
Hi.

Associating multiple algorithms with a given prefix is an interesting topic, 
and I think this can simplify the complexity of FlexAlgo. I wonder if the 
author would consider using cases with multiple algorithms with a given prefix.

Thanks

ZHibo

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


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://www.ietf.org/mailman/listinfo/lsr

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


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

2020-09-29 Thread Jia Chen
Not sure whether the use case that the underlay network and the overlay
network that belong to two different administrations is within this scope
?  or has it already been covered by some  other draft or RFCs? Assuming
there are multiple underlay paths from A to B. Overlay would like to
influence underlay path selections. How the best route can be selected, how
the traffic can be forwarded (for example, overlay is IPSec traffic) ?

Jay

On Tue, Sep 29, 2020 at 7:05 AM  wrote:

>
> 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  40juniper@dmarc.ietf.org> 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-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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr=DwIGaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY=
>
> ___
> Lsr mailing list
> Lsr@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr=DwIGaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY=
>
___
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

2020-09-29 Thread tony . li

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-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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr