[Roll] Fwd: draft-previdi-6man-segment-routing-header

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sat, 15 November 2014 06:16 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E4DF11A1A55 for <roll@ietfa.amsl.com>; Fri, 14 Nov 2014 22:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.494
X-Spam-Status: No, score=-14.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id r7uHzi-6BpOl for <roll@ietfa.amsl.com>; Fri, 14 Nov 2014 22:16:50 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC871A1A2C for <roll@ietf.org>; Fri, 14 Nov 2014 22:16:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8979; q=dns/txt; s=iport; t=1416032209; x=1417241809; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=p+eVB9j9kv10WS7rDTO4CofTIN27t9ILSRRgNDdVO/g=; b=MX3YnU+gKfGiSTMvMrymvWS2WqtVcr2qRD05IVpK28En7ewZ1ELxpNYf N0IklEzY0bK8p080XnfyUezVbfyKVQBSOgK80VuLo7ltbyKpn7UrDP02N uFFLPhfFg+3grzr0KFoyzSax9r241dfpDVoibq6XHOX6P8UxHUu5uhoH6 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,390,1413244800"; d="scan'208,217";a="369307006"
Received: from rcdn-core-12.cisco.com ([]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2014 06:16:49 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com []) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAF6GmIG015674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Sat, 15 Nov 2014 06:16:49 GMT
Received: from xmb-rcd-x01.cisco.com ([]) by xhc-aln-x05.cisco.com ([]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 00:16:48 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: ROLL WG <roll@ietf.org>
Thread-Topic: draft-previdi-6man-segment-routing-header
Thread-Index: AQHQAFbVfdYglDMLE0GUchpU6eOffZxhScYA///tBo0=
Date: Sat, 15 Nov 2014 06:16:48 +0000
Message-ID: <B250E09C-99CF-45B5-9997-942DD81A7692@cisco.com>
References: <54667C2C.6000509@gmail.com>,<5466AB5C.9070806@acm.org>
In-Reply-To: <5466AB5C.9070806@acm.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: multipart/alternative; boundary="_000_B250E09C99CF45B59997942DD81A7692ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/sAsqBrSiF7g0quAQEFId5ldZ_fc
Subject: [Roll] Fwd: draft-previdi-6man-segment-routing-header
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Nov 2014 06:16:53 -0000

This also relates to our discussion on whether a RH or a RPL option can be inserted or cause an extra  IPinIP encapsulation. Certainly the rule is to encapsulate.

This is where the Flow Label technique was of particular interest.

Now if we could go along the path of a routing dispatch where all the LLN routing artifacts are stored prior to the compressed packet we could probably make things innocuous.



Début du message transféré :

Expéditeur: Erik Nordmark <nordmark@acm.org<mailto:nordmark@acm.org>>
Date: 14 novembre 2014 15:24:44 UTC−10
Destinataire: Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>, 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Objet: Rép : draft-previdi-6man-segment-routing-header

On 11/14/14 12:03 PM, Brian E Carpenter wrote:

1. I simply don't understand one aspect of this proposal. Whenever I have
looked for it in RFC 2640, I have failed to find anything that allows
extension headers to be inserted in packets en route. But this draft
seems to require an ingress router to insert a header and an egress
router to remove it. Is that even allowed? And are we sure it has no
unintended side effects?

Doesn't work - breaks PMTUD (the origin receives a PTB which says MTU=X but sending packets of length X still fails due to the added headers). This should be in the "IP protocol FAQ" - I can't remember how many times Steve Deering had to correct this.

IPv6 extension headers can only be added together with an outer IPv6 header. That ensure that any ICMP errors are sent to the encapsulators, that can regenerate a ICMP error which will have the correct MTU value for the original sender.


2. There is no mention of MTU size or fragmentation. What happens if
the user packet plus the added header exceeds the network's MTU?

3. I think this model is completely orthogonal to the problem presented
by Behcet in draft-sarikaya-6man-sadr-overview.


IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6