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

Bruno,

please see inline:

On 20/10/2020 11:43, bruno.decraene@orange.com wrote:
> Peter,
> 
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>
>> Bruno,
>>
>> On 19/10/2020 18:52, bruno.decraene@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-bounces@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-drafts@ietf.org <internet-drafts@ietf.org>
>>>>> Sent: Tuesday, September 29, 2020 9:36 AM
>>>>> To: Parag Kaneriya <pkaneria@juniper.net>; Shraddha Hegde
>>>>> <shraddha@juniper.net>; Ron Bonica <rbonica@juniper.net>; Rajesh M
>>>>> <mrajesh@juniper.net>; William Britto A J <bwilliam@juniper.net>
>>>>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> [External Email. Be cautious of content]
>>>>>
>>>>>
>>>>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>>>>> has been successfully submitted by Ron Bonica and posted to the IETF
>>>>> repository.
>>>>>
>>>>> Name:           draft-bonica-lsr-ip-flexalgo
>>>>> Revision:       00
>>>>> Title:          IGP Flexible Algorithms (Flexalgo) In IP Networks
>>>>> Document date:  2020-09-29
>>>>> Group:          Individual Submission
>>>>> Pages:          14
>>>>> URL:            https://urldefense.com/v3/__https://www.ietf.org/id/draft-
>>>> bonica-
>>>>> 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
>>>
>>>
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> 
> 