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

"Adrian Farrel" <> Wed, 13 March 2019 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBEDF130F5B; Wed, 13 Mar 2019 06:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rQXrKutLx_RY; Wed, 13 Mar 2019 06:16:11 -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 518FE130F02; Wed, 13 Mar 2019 06:16:11 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x2DDG85w002823; Wed, 13 Mar 2019 13:16:09 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id C8B9622044; Wed, 13 Mar 2019 13:16:08 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id B302122042; Wed, 13 Mar 2019 13:16:08 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x2DDG7Qp030502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 13:16:07 GMT
From: Adrian Farrel <>
To: 'Mirja Kuehlewind' <>
Cc: 'Mirja Kühlewind via Datatracker' <>, 'The IESG' <>,,,,
References: <> <001601d4d8d4$2808d1c0$781a7540$> <>
In-Reply-To: <>
Date: Wed, 13 Mar 2019 13:16:05 -0000
Organization: Old Dog Consulting
Message-ID: <01ba01d4d99e$eade89e0$c09b9da0$>
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+VBQ9KaQwWAH98EEQAV9smsunFw5rsA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--14.015-10.0-31-10
X-imss-scan-details: No--14.015-10.0-31-10
X-TMASE-Result: 10--14.015100-10.000000
X-TMASE-MatchedRID: oHOSwQSJZWjxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizwJF2U8dKhm+Xtx Bj0owbAa8JDf06DACvODD2YsveSRAUi2Drj9KXXXA9lly13c/gGMoAOyyQDaY665pTV4nlyUmPY Pzc9U9ykZxkaSIDa7cPWHSLoU43ZYey2hwIiqvBOzI1v7J4hECvqPNYK78GMcut/GVGOoEnfReg 8IMPTbiiqGuIpmy1HAnQfu3ND6+pRJtzxaLxhtW5D6BbDN9+jO1kqyrcMalqUY0A95tjAn+1FPj tF42O5h5GQB1hOgRUQ9OBgxoSFyPNPxsjeTKRpTBfKxbfcZgylAq6/y5AEOOiJ8zskw0dbrJBDL QwAO11uEp6t9i7m0ai71R/jxbyBo3drJ6tQCW55I9rD1ir7Z9JZ6zKu0q4rtyWCL+8tLbvbtlt4 n4EC2BeL8GfmD/blkLUq1F8gGNyX/tH4UJZUAmZ4CIKY/Hg3AWQy9YC5qGvybk3ZgcwPRvwzKt8 /2P4LVIAcCikR3vq/apLNdXBrZ9ZGnpuAilcP+mJauI4tifr47dFn39uYUUFNNX6w4g5Ng
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: Wed, 13 Mar 2019 13:16:14 -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
>>   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.