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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 12 Mar 2019 03:53:08 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-sr-over-ip-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

These points should be easy to resolve:

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

2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN field and
eventually RFC2983 for DSCP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Mar 2019 13:04:40 -0000

Thanks Mirja,

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

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

Best,
Adrian

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Mar 2019 10:57:12 +0100

Hi Adrian,

Please see below.

> On 12. Mar 2019, at 14:04, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks Mirja,
> 

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.

>              configured dependent on the outgoing interface and payload.</t>

Yes, thanks!

Mirja

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Mar 2019 13:16:05 -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.
>> 
> 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.

>>            configured dependent on the outgoing interface and payload.</t>

Perfect. It's in my working copy.

Best,
Adrian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Mar 2019 09:02:46 -0500

For the IESG ...

On Wed, Mar 13, 2019 at 8:16 AM Adrian Farrel <[email-masked]> wrote:

> 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