Re: [mpls] Mirja Kühlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

Mirja Kuehlewind <> Wed, 13 March 2019 09:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E4EF130EDC; Wed, 13 Mar 2019 02:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DM0yTcjgki_p; Wed, 13 Mar 2019 02:57:17 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E1E1130EBF; Wed, 13 Mar 2019 02:57:17 -0700 (PDT)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h40dN-0008NR-AF; Wed, 13 Mar 2019 10:57:13 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Mirja Kuehlewind <>
In-Reply-To: <001601d4d8d4$2808d1c0$781a7540$>
Date: Wed, 13 Mar 2019 10:57:12 +0100
Cc: Mirja Kühlewind via Datatracker <>, The IESG <>,,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <001601d4d8d4$2808d1c0$781a7540$>
X-Mailer: Apple Mail (2.3445.101.1)
X-HE-SMSGID: 1h40dN-0008NR-AF
Archived-At: <>
Subject: Re: [mpls] Mirja Kühlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Mar 2019 09:57:20 -0000

Hi Adrian,

Please see below.

> On 12. Mar 2019, at 14:04, Adrian Farrel <> wrote:
> Thanks Mirja,
>> 1) Given section 3.1, the following drafts all seems that they should be
>> normative references: ietf-isis-encapsulation-cap, ietf-ospf-encapsulation-cap,
>> ietf-ospf-segment-routing-extensions, ietf-isis-segment-routing-extensions
> Well, that wasn't the intention. It is meant to be an example of how the forwarding entries are constructed.
> As it says at the top of Section 3...
>   Note that the examples in
>   Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in
>   fact, other mechanisms of discovery and advertisement could be used
>   including other routing protocols (such as BGP) or a central
>   controller.
> We could be more explicit in section 3.1 so that, for example...
>   o  The Segment Routing Global Block (SRGB) is defined in [RFC8402].
>      Router E is SR-MPLS capable, so it advertises an SRGB as described
>      in [I-D.ietf-ospf-segment-routing-extensions] and
>      [I-D.ietf-isis-segment-routing-extensions].
>   o  The Segment Routing Global Block (SRGB) is defined in [RFC8402].
>      Router E is SR-MPLS capable, so it advertises an SRGB to the other
>      SR-MPLS capable routers.  If an IGP is in use then Router E behaves
>      as described in [I-D.ietf-ospf-segment-routing-extensions] and
>      [I-D.ietf-isis-segment-routing-extensions], but other mechanisms
>      Could be applied.
> We'd need to make similar changes throughout the section.
> Would such changes be enough for you?

It still sounds to me that these document are basically a must read to understand the full picture. Do you think it would be a problem or the wrong thing to make these reference normative?

However, your wording change makes it definitely more clear that this is only one example. If the wg and responsible ADs think, it’s the right thing to do to leave the reference informative, I will clear my discuss.

>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN
>> field and eventually RFC2983 for DSCP.
> That's good. Thanks. It gives us...
>              <t hangText="IP Header Fields:">When encapsulating an MPLS
>              packet in UDP, the resulting packet is further encapsulated in
>              IP for transmission. IPv4 or IPv6 may be used according to the
>              capabilities of the network. The address fields are set as
>              described in <xref target="usecases"/>. The other IP header
>              fields (such as the ECN field <xref target="RFC6040"/>, the DSCP 
>              code point <xref target="RFC2983"/>, or IPv6 Flow Label) on each
>              UDP-encapsulated segment SHOULD be configurable according to the
>              operator&apos;s policy: they may be copied from the header of the
>              incoming packet; they may be promoted from the header of the
>              payload packet; they may be set according to instructions
>              programmed to be associated with the SID; or they may be
>              configured dependent on the outgoing interface and payload.</t>

Yes, thanks!


> Best,
> Adrian