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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 13 March 2019 13:16 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDF130F5B; Wed, 13 Mar 2019 06:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQXrKutLx_RY; Wed, 13 Mar 2019 06:16:11 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518FE130F02; Wed, 13 Mar 2019 06:16:11 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2DDG85w002823; Wed, 13 Mar 2019 13:16:09 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8B9622044; Wed, 13 Mar 2019 13:16:08 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id B302122042; Wed, 13 Mar 2019 13:16:08 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (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
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>
Cc: 'Mirja Kühlewind via Datatracker' <noreply@ietf.org>, 'The IESG' <iesg@ietf.org>, mpls@ietf.org, loa@pi.nu, mpls-chairs@ietf.org, draft-ietf-mpls-sr-over-ip@ietf.org
References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net>
In-Reply-To: <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net>
Date: Wed, 13 Mar 2019 13:16:05 -0000
Organization: Old Dog Consulting
Message-ID: <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk>
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-Originating-IP: 87.112.237.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24486.007
X-TM-AS-Result: No--14.015-10.0-31-10
X-imss-scan-details: No--14.015-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24486.007
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: <https://mailarchive.ietf.org/arch/msg/mpls/hHE_IKMxYbGaPfWFxr-Ip5dg8aM>
Subject: Re: [mpls] Mirja Kühlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=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.

Best,
Adrian