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:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com
Sent: Monday, September 03, 2018 2:07 PM
To: spr...@ietf.org
Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: [Lsr] Entropy label for SR-MPLS
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.
_
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 erreu
