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

"Adrian Farrel" <> Tue, 12 March 2019 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2379130F39; Tue, 12 Mar 2019 06:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kUo6t4FoCdOJ; Tue, 12 Mar 2019 06:04:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94A5130F70; Tue, 12 Mar 2019 06:04:45 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x2CD4h5o009474; Tue, 12 Mar 2019 13:04:43 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 90D8A22050; Tue, 12 Mar 2019 13:04:43 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 83A952204E; Tue, 12 Mar 2019 13:04:43 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x2CD4gSn004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Mar 2019 13:04:42 GMT
From: Adrian Farrel <>
To: 'Mirja Kühlewind via Datatracker' <>, 'The IESG' <>
Cc:, 'Loa Andersson' <>,,,
References: <>
In-Reply-To: <>
Date: Tue, 12 Mar 2019 13:04:40 -0000
Organization: Old Dog Consulting
Message-ID: <001601d4d8d4$2808d1c0$781a7540$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWKcwl0EQ
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--9.378-10.0-31-10
X-imss-scan-details: No--9.378-10.0-31-10
X-TMASE-Result: 10--9.378300-10.000000
X-TMASE-MatchedRID: QW5G6BKkLTrxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizwJF2U8dKhm+Xtx Bj0owbAa8JDf06DACvODD2YsveSRAUi2Drj9KXXXA9lly13c/gGMoAOyyQDaY665pTV4nlyUmPY Pzc9U9ykZxkaSIDa7cPWHSLoU43ZYey2hwIiqvBOzI1v7J4hECvqPNYK78GMcC/+dM49Ci+xpV1 CxFK6KOz4ycP3GnebWhUP7LVPwROAYkHOTosTds9xajlW+zwxCFIStk4KoNF0OAHqXajwVGAMRO zuQMTFrU0MXT8sFhvJftuJwrFEhTf306Q4zhC4D3QfwsVk0UbuGrPnef/I+epjAUsJ3ToshKlGS Rg0L+/10o/bsyGLnXPWwl0rq794xug58UuBS7ec=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
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: Tue, 12 Mar 2019 13:04:54 -0000

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

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
   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?

> 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>