Bruno,
On 20/10/2020 14:47, [email protected] wrote:
Peter,
From: Peter Psenak [mailto:[email protected]]
Bruno,
please see inline:
On 20/10/2020 11:43, [email protected] wrote:
Peter,
From: Peter Psenak [mailto:[email protected]]
Bruno,
On 19/10/2020 18:52, [email protected] 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 encoding to use.
thanks,
Peter
Thanks,
--Bruno
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:[email protected]] On Behalf Of Ron Bonica
Sent: Tuesday, September 29, 2020 3:38 PM
To: [email protected]
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: [email protected] <[email protected]>
Sent: Tuesday, September 29, 2020 9:36 AM
To: Parag Kaneriya <[email protected]>; Shraddha Hegde
<[email protected]>; Ron Bonica <[email protected]>; Rajesh
M
<[email protected]>; William Britto A J <[email protected]>
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
[email protected]
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
[email protected]
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.
_________________________________________________________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
