Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C89F01F0C5@MISOUT7MSGUSRDE.ITServices.sbc.com>
Date: Mon, 6 May 2019 14:39:23 +0200
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>,
 "mpls@ietf.org" <mpls@ietf.org>,
 "draft-ietf-mpls-sr-over-ip@ietf.org" <draft-ietf-mpls-sr-over-ip@ietf.org>,
 The IESG <iesg@ietf.org>, "loa@pi.nu" <loa@pi.nu>,
 "BRUNGARD, DEBORAH A" <db3546@att.com>,
 Alvaro Retana <aretana.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <59C94325-1724-4871-ADA4-C46C947ED072@kuehlewind.net>
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>
 <014401d4fdeb$182978e0$487c6aa0$@olddog.co.uk>
 <F64C10EAA68C8044B33656FA214632C89F01F0C5@MISOUT7MSGUSRDE.ITServices.sbc.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/r99EcdGg-f_jwbirVp5uVSgOwCw>
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,

Sorry for my late reply. Didn=E2=80=99t realise that there was a request =
for me in your earlier mail. I understand the situation and I agree that =
generalising it probably the better alternative. However, I agree with =
Alvaro, that probably more details should be given what the requirements =
from the named examples are and how this could be applied similarly for =
other protocols in future.

I will clear my discuss now, as this is part of Alvaro=E2=80=99s discuss =
and he is probably the better person to follow up with.

Mirja




> On 2. May 2019, at 20:39, BRUNGARD, DEBORAH A <db3546@att.com> wrote:
>=20
> Hi,
>=20
> I'm not sure if you were holding your breath on my answer=F0=9F=98=8A
>=20
> As Adrian noted, we have moved away from specifying a specific IGP (or =
two). Similar to draft-ietf-pce-segment-routing (recently approved) =
where we also took the informative approach. So I definitely support =
here the same approach. We do need to be future proof, IGPs are no =
longer the only technology in town - hopefully Acee is not reading =
this=F0=9F=98=8A
>=20
> Alvaro's suggestions on generalizing are very helpful and I think will =
help to clarify these are examples.
>=20
> Thanks,
> Deborah
>=20
> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Adrian Farrel
> Sent: Sunday, April 28, 2019 1:52 PM
> To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>
> Cc: mpls-chairs@ietf.org; mpls@ietf.org; =
draft-ietf-mpls-sr-over-ip@ietf.org; 'The IESG' <iesg@ietf.org>; =
loa@pi.nu
> Subject: RE: Mirja K=C3=BChlewind's Discuss on =
draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)
>=20
> Hi Mirja,
>=20
> 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.
>=20
> 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").
>=20
> 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.
>=20
> Thanks,
> Adrian
>=20
> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk>
> 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)
>=20
> Hi Mirja,
>=20
> Sorry to be a long time on this.
>=20
> 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.
>=20
> 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.
>=20
> Thanks for your patience.
>=20
> Adrian
>=20
> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk>
> 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)
>=20
> Thanks Mirja,
>=20
>>>> 1) Given section 3.1, the following drafts all seems that they=20
>>>> should be normative references: ietf-isis-encapsulation-cap,=20
>>>> 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=20=

>>> 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?
>>=20
>> It still sounds to me that these document are basically a must read =
to=20
>> understand the full picture. Do you think it would be a problem or =
the=20
>> wrong thing to make these reference normative?
>>=20
>> However, your wording change makes it definitely more clear that this=20=

>> is only one example. If the wg and responsible ADs think, it=E2=80=99s =
the=20
>> right thing to do to leave the reference informative, I will clear my=20=

>> discuss.
>=20
> I was worried about the rate of progress of SR documents. There has =
been a tendency for them to travel a little slowly.
>=20
> 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.
>=20
>>>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the =
ECN=20
>>>> 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=20
>>> payload.</t>
>>=20
>> Yes, thanks!
>=20
> Perfect. It's in my working copy.
>=20
> Best,
> Adrian
>=20