Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Mirja Kuehlewind'" <ietf@kuehlewind.net>
Cc: "'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>
 <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk>
 <07ac01d4f213$bd8e5870$38ab0950$@olddog.co.uk>
In-Reply-To: <07ac01d4f213$bd8e5870$38ab0950$@olddog.co.uk>
Date: Sun, 28 Apr 2019 18:52:00 +0100
Organization: Old Dog Consulting
Message-ID: <014401d4fdeb$182978e0$487c6aa0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWAH98EEQAV9smssCTdfKAQHTVUoipz7OVQA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OELaxfV2xZNe0afO0nSJcu2wXoo>
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 Mirja,

I have been looking at your Discuss. It seems that at least one of the =
referenced documents is hung up in the working group and is some way =
from becoming an RFC.

We tend not to like to write documents that (appear to) favour one of =
the two IGPs, so I am not comfortable with the idea of making one IGP =
normative and the other informative. I think the solution here is to =
make the whole of section 3.1 just use the IGPs as an example (taking =
out 2119 language and making it very clear that "other flooding =
mechanisms are available").

I wanted to get your OK on this approach (it sounded from your reply =
that you would be OK if the responsible AD was OK). I believe that, per =
Alvaro's Discuss, we will also need some generic text to establish the =
process divorced from any particular protocol mechanism.

Thanks,
Adrian

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk>=20
Sent: 13 April 2019 17:13
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>
Cc: '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
Subject: RE: Mirja K=C3=BChlewind's Discuss on =
draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

Hi Mirja,

Sorry to be a long time on this.

It looks like your concerns around the various OSPF and ISIS drafts has =
thrown up a "challenge".
One of the references (draft-ietf-isis-encapsulation-cap) is missing in =
action, and seems to have been abandoned.

This will necessitate some work on the draft to abstract the mechanisms =
described into general terms and avoid the need to reference at least =
this one draft, and maybe all four of the IGP drafts.

Thanks for your patience.

Adrian

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk>=20
Sent: 13 March 2019 13:16
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>
Cc: '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
Subject: RE: Mirja K=C3=BChlewind's Discuss on =
draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

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
>>=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=20
> 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.

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.
>>=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!

Perfect. It's in my working copy.

Best,
Adrian