Subject: [Lsr] Entropy label for SR-MPLS

From: <[email-masked]>
Date: Mon, 3 Sep 2018 12:06:50 +0000

Hi SPRING WG,

draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPLS entropy labels in SR-MPLS networks.
https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05

As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. It improves load-balancing / allows the effective use of parallel paths. It requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As segment routing does not uses LDP nor RSVP-TE, an IGP extension is indeed required. https://tools.ietf.org/html/rfc6790

As of today (-05) the IGP encoding chosen by draft-ietf-isis-mpls-elc:
- may support inter-area/level deployments, albeit with additional complexity (currently not specified)
- does not support inter-AS and inter-protocol deployments. (Inter-protocol being the redistribution of prefixes/segments from a protocol (instance) to another IGP protocol (instance))

Following some discussions, this restriction is not an IGP technical issue as it would be easy to allow for this feature by using a different IGP encoding. It's a question of requirements so it would be better discussed in the SPRING WG.

I'd like to see a discussion on whether this restriction is a good or a bad thing from a SPRING requirement standpoint.
In other words, do we want to allow (or not) the use of entropy label in inter-AS and inter-protocol deployments or do we accept this regression compared to LDP and RSVP-TE?

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Mon, 3 Sep 2018 12:37:32 +0000

Speaking as an individual contributor and a service provider,

1) ELC (Entropy Label Capability)
I support the ability to use entropy label and hence advertise ELC (Entropy Label Capability) inter-AS and inter-protocol deployments
- In Orange we do have both inter-area/level and inter-AS w/ inter-protocol deployments, in particular for the support of MPLS VPNs across ASes.
- I don't see a reason to introduce such limitation to segment routing (compared to LDP & RSVP-TE) especially as this feature could easily be supported by the IGP extension.

2) ERLD (Entropy Readable Label Depth)
On a side note, as the draft also defines the IGP extension to advertise ERLD (Entropy Readable Label Depth) I don't think that we (equally) need to propagate ELRD advertisement between areas/levels/ASes/protocols as:
- ELC advertisement is a MUST while ERLD is both only nice to have and only required for SR-policies with "many" labels, which should be the minority in most deployments
- ELC only requires the advertisement of a flag per segment/prefix which can easily be propagated between IGP topologies. While the use of ERLD requires the knowledge of the IGP topology, which by definition is not available in inter-area/level/AS/protocol scenarios.
  I see two main cases of the use of ERLD in inter AS scenario:
            - along the shortest path: in this case, only one or two labels/SIDs is required hence ERLD is not a concern. (Note that this applies to any type of metric and to Flex Algo)
            - along a TE/specific path: in this case, the computation of the path requires the knowledge of the topology along the path, hence the LSDB of both ASes. It would typically be performed by a PCE rather than the ingress node (although the ingress could also learn the remote topology, e.g. with BGP-LS)
In summary, in both cases there is no need to propagate the ERLC between LSDB

Thanks,
Regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 03, 2018 2:07 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Lsr] Entropy label for SR-MPLS

Hi SPRING WG,

Thanks,
Regards,
--Bruno

Thank you.