[Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

<stephane.litkowski@orange.com> Fri, 09 November 2018 14:30 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E0D130E08; Fri, 9 Nov 2018 06:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKyMIpeG1fSR; Fri, 9 Nov 2018 06:30:22 -0800 (PST)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90E41277C8; Fri, 9 Nov 2018 06:30:21 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 42s2cX4KSQz2009; Fri, 9 Nov 2018 15:30:20 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42s2cX3P5Yz8sYT; Fri, 9 Nov 2018 15:30:20 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 15:30:20 +0100
From: <stephane.litkowski@orange.com>
To: "lsr@ietf.org" <lsr@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Thread-Index: AdR4OJWYmH00pYTzTK6gvxR+PFXbGg==
Date: Fri, 9 Nov 2018 14:30:19 +0000
Message-ID: <9208_1541773820_5BE599FC_9208_47_1_9E32478DFA9976438E7A22F69B08FF924B746E6A@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924B746E6AOPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/91nW-bhwjnsCCky6D4AmKOBIeVQ>
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 14:30:24 -0000

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy label capability for SR but we hadn't found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have participated to this discussion.

Following this discussion, we are coming with the following proposal that the WG need to validate:

The entropy label capability is still considered as a per node property (for simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure that the tail-end of the segment is entropy label capable otherwise packets will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability of the node who has firstly originated the prefix, should be associated to the prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by a local configuration and for leaked/redistributed prefixes. When a prefix is leaked or redistributed, the ELC associated to the prefix may be also leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the prefix associated to the Node/Prefix segment as the ELC set in the Prefix Attributes.
An ingress should set the entropy label below an Adjacency segment only if the adjacent neighbor of the node that has advertised the Adj SID is advertising an ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding SID, there is nothing to do in these drafts.


Let us know your comments/feedback on this proposal so we can progress these documents.

Brgds,

Stephane


_________________________________________________________________________________________________________________________

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.