Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk>
Date: Wed, 13 Mar 2019 10:57:12 +0100
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind_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
Content-Transfer-Encoding: quoted-printable
Message-Id: <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net>
References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com>
 <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk>
To: adrian@olddog.co.uk
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/h1xAHCXj1HlWf2sZ5qVYB-7HTok>
Subject: Re: [mpls] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?=
 =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?=
Precedence: list

Hi Adrian,

Please see below.

> On 12. Mar 2019, at 14:04, Adrian Farrel <adrian@olddog.co.uk> wrote:
>=20
> Thanks Mirja,
>=20
>> 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
>=20
> Well, that wasn't the intention. It is meant to be an example of how =
the forwarding entries are constructed.
>=20
> 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.
>=20
> We could be more explicit in section 3.1 so that, for example...
>=20
> 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
>=20
> We'd need to make similar changes throughout the section.
>=20
> 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=E2=80=99s the =
right thing to do to leave the reference informative, I will clear my =
discuss.

>=20
>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN
>> field and eventually RFC2983 for DSCP.
>=20
> That's good. Thanks. It gives us...
>=20
>              <t hangText=3D"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=3D"usecases"/>. The other IP =
header
>              fields (such as the ECN field <xref target=3D"RFC6040"/>, =
the DSCP=20
>              code point <xref target=3D"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!

Mirja


>=20
> Best,
> Adrian
>=20
>=20