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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 14 March 2019 14:03 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 DF3CD130DD6; Thu, 14 Mar 2019 07:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 psuL9ijVBChq; Thu, 14 Mar 2019 07:03:00 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61611129B88; Thu, 14 Mar 2019 07:03:00 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id m13so4316170lfb.6; Thu, 14 Mar 2019 07:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LniJoLF77kVePKnv56PsnDt6ncxl8UWDqqsa3jhnXb0=; b=Gw9xsLlU/7Q5fTbS8zQNo6ax/mmp/+7a37yN6wb9T0oJ9bU0GmYicQvxQqJkcQVLUW nsBe2Njd/LIv/YTfHGXmQEPZaByTD6mVFQfL8/HifPXP9XeCjWfnYi4tC41jEp+tincc T3dhNhqkPzFU1AASvhIKHcOmx5Be7vP7YlUDwtdsWwiMH+JqJzY45nnwhF5T8HkNYYat MkMGx+/BwNnogPkVBRu0TWKeWp3cbIfKYBKk7cFspU9NMHCibiRBng4hmYBdj9K6Dxo9 BzWS8AS7Ixf+QhYH55TWr6BifeVFPmPGKDQvLiBg7GxKHhzAzf8lizLjwWFSg3oTHxuT RCJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LniJoLF77kVePKnv56PsnDt6ncxl8UWDqqsa3jhnXb0=; b=MXAMYPejZILVxWoiJ2FvM5u5bYFkiAm/EvDWF1IOjqvtmalQyV6zkyCwHEB9Q41fEy 0UFbr6IpeZyAw0c/RBfakF362AmE7RtH9uJm4p5mbNahD6a+RAJ4hUz+/+A63YgIRLxE j4SSz12k6o4uCQOLIOa1/A52XNqQu2oyclKc/6jP9NA6pf5UGZhMo+UY/kbM4gL62231 gd00JTxBnYNWwsskqFOOt6P7CTOvrQeDDcqutWQlskaRVVCQBO5Yy7SGeFx1/MMmpeuU 0dh2nPZFFt+BI9OUf4EEiaGicXT14tTc5PWOwRsTWfYMeThhNeV5lf9uGqbk9KcOsj/E RQnA==
X-Gm-Message-State: APjAAAUAhZsTHnziVAKa/MMz9NyBrsHNFlu7eK6PmdykYf6bCpmTd27O 3TFJ9B4sTWRHPP+2GPi5NX8/9hpb1W9MRj8GzjHbqQO2
X-Google-Smtp-Source: APXvYqzWOfboOiGHAoPqSg+XD9G/2+NIHrN678ISJ79r7jCuPnqKVhrgxZaLt16Qa91IMJRwhG0WZeJzQFuXlel+P18=
X-Received: by 2002:a19:9e0d:: with SMTP id h13mr11879606lfe.51.1552572178174; Thu, 14 Mar 2019 07:02:58 -0700 (PDT)
MIME-Version: 1.0
References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk>
In-Reply-To: <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 14 Mar 2019 09:02:46 -0500
Message-ID: <CAKKJt-d45NxsC31FnpwdACW33NALZ0fMcXm-DMUYu+uMoHBjhQ@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, mpls@ietf.org, draft-ietf-mpls-sr-over-ip@ietf.org, Mirja Kühlewind via Datatracker <noreply@ietf.org>, mpls-chairs@ietf.org, The IESG <iesg@ietf.org>, Loa Andersson <loa@pi.nu>
Content-Type: multipart/alternative; boundary="0000000000002b2a4505840e61a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/YWtTgmm45zMyGfKR3J2TmJb24nY>
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: Thu, 14 Mar 2019 14:03:04 -0000

For the IESG ...

On Wed, Mar 13, 2019 at 8:16 AM Adrian Farrel <adrian@olddog.co.uk> 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...
> >>
> >> 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.
>

"Deadly clusters" would be a FABulous retreat topic for the next IESG. I'm
stepping down after three terms on the IESG,and I have documents in C238 (
https://www.rfc-editor.org/cluster_info.php?cid=C238) that have been in the
RFC Editor queue since halfway through my first term. We've even updated
stuff that's been in this cluster but hasn't been published yet, which
confused the heck out of everyone. "Living PS", anyone?

Spencer

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