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

"Adrian Farrel" <> Sat, 13 April 2019 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF3F712077A; Sat, 13 Apr 2019 09:12:55 -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 bUqV9nVaLs-R; Sat, 13 Apr 2019 09:12:53 -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 835E0120784; Sat, 13 Apr 2019 09:12:52 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x3DGCoHY008999; Sat, 13 Apr 2019 17:12:50 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8CE9F2203B; Sat, 13 Apr 2019 17:12:50 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 771792203A; Sat, 13 Apr 2019 17:12:50 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x3DGCnZ6007839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 17:12:49 +0100
From: Adrian Farrel <>
To: 'Mirja Kuehlewind' <>
Cc: 'Mirja Kühlewind via Datatracker' <>, 'The IESG' <>,,,,
References: <> <001601d4d8d4$2808d1c0$781a7540$> <> <01ba01d4d99e$eade89e0$c09b9da0$>
In-Reply-To: <01ba01d4d99e$eade89e0$c09b9da0$>
Date: Sat, 13 Apr 2019 17:12:48 +0100
Organization: Old Dog Consulting
Message-ID: <07ac01d4f213$bd8e5870$38ab0950$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWAH98EEQAV9smssCTdfKAac1vdSA
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--18.178-10.0-31-10
X-imss-scan-details: No--18.178-10.0-31-10
X-TMASE-Result: 10--18.177700-10.000000
X-TMASE-MatchedRID: dL10VBB8yofxIbpQ8BhdbFt3XMydUaMXLi2dwKiMR9zoN8DSoota+V6y p3EumDgAUzY1l1iGPWoG6mTN8w5BdCo5l3eEOvf4M8ORI7N4NZYZKp0SZ4P+dRSX1u8BLtZAf/b TCoZRptLnjmT3vqmhOTmv3FUjxYfb+dVjQNaxOrfx5KZMlKYS/aCjvIRDW3XL7ZuNmL4Rc2cHam +XwtBHJZbTSn0tZbEPxQLjVhHavMRPTVZStLvd9aEtILqFekmXecvjbu/xDjpQvOmOsSGiOn2pM 3AyIoP6jSdD+01MNLeOFODziXK8yuZjHoPEX7J1x0PDBzN98K438FNTll9lEu0wjaPq2nvfzuet 2h7oDk6xMDN1c6KuVwWrcvH5RNpBo+j4/L5PWT6WLCkl1lq7BxeKvIXZmbwIJcnDRagjAEYHLwG BIqXN8WaCsIMzyrAtp7VeNu6PRVSKV2xHgiv1d01Wvi92YKnOLJXjpJzQSNM52X8YwVUEW6NHQr uNJthYuAdGWKB0A5Lbu2Nc/AXe5nKKXnQ8W+xG/1aBDnIV4ikIjen4m7yaquXZ6Ej4+VCNo8WMk QWv6iWhMIDkR/KfwP306Q4zhC4D3QfwsVk0UbtuRXh7bFKB7qcesiNhzfvi/2dqCfCt3yyhSyta VO0PrTIBl1e0jGZnYDttQUGqHZU=
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: Sat, 13 Apr 2019 16:12:56 -0000

Hi Mirja,

Sorry to be a long time on this.

It looks like your concerns around the various OSPF and ISIS drafts has thrown up a "challenge".
One of the references (draft-ietf-isis-encapsulation-cap) is missing in action, and seems to have been abandoned.

This will necessitate some work on the draft to abstract the mechanisms described into general terms and avoid the need to reference at least this one draft, and maybe all four of the IGP drafts.

Thanks for your patience.


-----Original Message-----
From: Adrian Farrel <> 
Sent: 13 March 2019 13:16
To: 'Mirja Kuehlewind' <>
Cc: 'Mirja Kühlewind via Datatracker' <>; 'The IESG' <>;;;;
Subject: RE: Mirja Kühlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

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...
>> OLD
>>   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].
>> NEW
>>   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.
>> END
>> 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.

I was worried about the rate of progress of SR documents. There has been a tendency for them to travel a little slowly.

It looks like these documents have all now progressed far enough, but they are caught up in a deadly cluster of missing references (cluster 340). We'll have a look through the cluster to see how dangerous it is and make normative references where we can.

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

Perfect. It's in my working copy.