Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6830bis-16: (with DISCUSS and COMMENT)

Dino Farinacci <> Tue, 11 September 2018 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73156130EC6; Tue, 11 Sep 2018 08:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CCt6CbI5TPOF; Tue, 11 Sep 2018 08:59:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C097130EC1; Tue, 11 Sep 2018 08:59:55 -0700 (PDT)
Received: by with SMTP id s13-v6so12447937pfi.7; Tue, 11 Sep 2018 08:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rd1cVMmTMyVtt/r/jpn1hsBiD+Vn5rXYZ9SRI4vpeH0=; b=L7Td+hcHlbtufPuonaa9p1Mi3UxrebpojZeofrFXqif/7LiYmUdY0xdc7Jm4KGPBSf +qVzpoE9ilY59LTDRIIID9sQHim+X1IuRy+tbJiNCk3CxkKvRiNv3qwHEaNvVCaNlHTp /H8HbGfro09CRX4574K2asLmcdAe90sYhfhUPVfvzuoxpUztHbR6LvuNz5WmxHlOhlUp zAbHiWWRsLldSglLnUYGVJLvotAJ3Rki9t1V7XBZ8NVaa0hoTmweA62ztEFksoSGDl03 YJ9tG/wWX6GA+xZtlSWi3xjYaDbW9lnJsGYJKlRN2Wma/uBSBNZgdXwEQOo1PdpCnTU/ WRYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rd1cVMmTMyVtt/r/jpn1hsBiD+Vn5rXYZ9SRI4vpeH0=; b=YqyvxNAhuYmfuPdJr62C7H7no6i/vDIAk3/FNgZHBaL6dHc74ov07xR9+RkCGQNRxK tRvLAHNj51syXuM6yEOoipKOvUjg38HlgPXDhf3qb51fLUlaWYd9AojkNQrMN/+eDywW hUc4/z2QupzOxKnMgQ5xwdI1HG68PaoGGb2ST1NlE9zF6yzscgA788VTYrs1QfVJ7n3x gW5toyrWWuBUprreNwBWfRwsqbKqkHfaUteLgBJas5+Ql8dHjo3ylX1w1bHKOwD3R3Wg CHpyyCqpQ4KoNshkZq9I/OpYrVfjm7HL+R009qf3oD0/9BahwhlWTGtICiMTKrkSrJ1m v6Ww==
X-Gm-Message-State: APzg51AOBCFyJnAgpD71lWzugM3eLEbn0Eu9/qK8wjv402qgD2Vmcuea 4kYXlzzSl6R72TjnQ9TjjRI=
X-Google-Smtp-Source: ANB0Vdaz6hde/tY9Gxr1R/8B7BZfDTwTB4EZCqjOzKsFYedhS9CK6VYsbOMNUFb4kYdqySqIWJg4UQ==
X-Received: by 2002:a63:6343:: with SMTP id x64-v6mr29343573pgb.173.1536681594706; Tue, 11 Sep 2018 08:59:54 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g25-v6sm38524745pfd.23.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:59:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Tue, 11 Sep 2018 08:59:53 -0700
Cc: The IESG <>,, Luigi Iannone <>,, Dino Farinacci <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 15:59:57 -0000

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-lisp-rfc6830bis-16: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:

Thanks for your comments Mirja.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I have a couple of smaller discuss points with should be straight-forward to
> address and one more high-level discussion point that might not have a solution
> (depending on the deployment status of LISP I guess) but I would like to at
> least have a discussion. I start with the straight-forward onces:
> 1) Unfortunately ECN decapsulation is slightly more complicated than described
> in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly
> (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)!
> (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure
> that is helpful).

Well it doesn’t have to be. I am a bit hesitant to just point to another long complicated RFC. This text has gone through review for quite a long time and many ECN experts decided we should write it this way. And this text did go through IESG review when RFC6830 was made experimental RFC.

> 2) Further, also in sec 5.3:
> "The inner-header 'Differentiated Services Code Point' (DSCP) field
>      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
>      copied from the outer-header DSCP field ('Traffic Class' field, in
>      the case of IPv6) considering the exception listed below."
> However, I didn't find any exceptions listed later in the doc. However, setting
> the DSCP field might also be matter of local policy. E.g. if DSCP is not used
> for a different purpose in the receiver side LISP network, it could make sense
> to restore/keep the original value in the inner header.

This is a dangling reference where the “text below” was removed or reworded. So I will remove this reference.

> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while
> "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

This is discussed in length. I don’t know how you could have missed this.

> 4) I would like to see another sentence in section 12 explicitly stating that
> the source port SHOULD be the same for all packet belong to the same flow.


> 5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet."
> What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or
> maybe the packet should be dropped or something? Please clarify in the doc!

If they are both set, there is text in the docuemnt that already says:

          <t hangText="N:">The N-bit is the nonce-present bit. When             
          this bit is set to 1, the low-order 24 bits of the first 32           
          bits of the LISP header contain a Nonce. See <xref
          target="echo-nonce"/> for details. Both N- and V-bits MUST            
          NOT be set in the same packet. If they are, a decapsulating           
          ETR MUST treat the 'Nonce/Map-Version' field as having a              
          Nonce value present.</t>

> 6) And now the more-discussion-needed point:
> So my underlying concern is the same as brought up by the TSV-ART review that
> lisp information are not end-to-end integrity protected or authenticated.

I would like you to be more specific. Beacuse there is a lot of security in the protocol and we believe the current drafts, in their entirety, inicdate so.

> However, while briefly thinking about how this could be eventually realized, I
> noticed that there is actually no mechanism to extend the LISP header in any

Right, by design so it is efficient for hardware AND software forwarding. But we do have the LISP-GPE header that can be used for extensions. But that has limited deployment.

> way. There is no version, no option and the LISP header seems to have a fixed,

We decdied as a working group that the UDP port number would indicate what header follows and therefore what LISP version is used.

> implicitly specified length without an explicit length field. This seems too

That is right, the header is 8 bytes, fixed, by design.

> late to add any kind of extensibility mechanism at this stage of the protocols
> lifetime, however, I would still like to discuss if there was any discussion
> about extensibility, what was the reason to chose this approach, and potential
> if some background about the choice should be given in the doc.

Well the original authors didn’t believe in having a lot of options in protocols, otherwise it will cause more un-interoperability. But has time has gone on, I believe we made the right choices, and have discovered that LISP is quite extensible, and even 10 years after the the original design, we can continue to add more LISP use-cases with the same basic protocol.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the
> language to more what RFC4459 recommends: OLD "This behavior is performed by
> the ITR when the source host originates
>   a packet with the 'DF' field of the IP header set to 0."
> "This behavior MAY be performed by the ITR only when the source host originates
>   a packet with the 'DF' field of the IP header set to 0.

Changed. Thanks for the suggestion.

> 2) Sec 4: "...this document recommends that a maximum of two
>   LISP headers can be prepended to a packet."
> "it is RECOMMENDED that a maximum of two
>   LISP headers can be prepended to a packet.”


Thanks again,