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

"BRUNGARD, DEBORAH A" <db3546@att.com> Thu, 02 May 2019 18:39 UTC

Return-Path: <db3546@att.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 8BFE71200B6; Thu, 2 May 2019 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.237
X-Spam-Level:
X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 EQjfJnqKEeXK; Thu, 2 May 2019 11:39:12 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28F812008F; Thu, 2 May 2019 11:39:12 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x42ITCa4030692; Thu, 2 May 2019 14:39:11 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2s85p58skq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 May 2019 14:39:11 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x42Id9xq025699; Thu, 2 May 2019 14:39:11 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x42Id3Nk025566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 May 2019 14:39:04 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 89C5E40392B4; Thu, 2 May 2019 18:39:03 +0000 (GMT)
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27129.vci.att.com (Service) with ESMTPS id 6DFA04039295; Thu, 2 May 2019 18:39:03 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.184]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0439.000; Thu, 2 May 2019 14:39:03 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Mirja Kuehlewind'" <ietf@kuehlewind.net>
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>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tcGxz?= =?utf-8?Q?-sr-over-ip-03:_(with_DISCUSS)?=
Thread-Index: AQHU2MHM3K0ltn3WX0eeMXWY7Lb8DKYIOdgAgAFd9ACAADeSgIAw6aUAgBeusACABhEfEA==
Date: Thu, 2 May 2019 18:39:02 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C89F01F0C5@MISOUT7MSGUSRDE.ITServices.sbc.com>
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>
In-Reply-To: <014401d4fdeb$182978e0$487c6aa0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.215.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-02_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905020118
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/tVkTA5HnkWbw3vagyXzQkqBs2MI>
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?=
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, 02 May 2019 18:39:15 -0000

Hi,

I'm not sure if you were holding your breath on my answer­čśŐ

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­čśŐ

Alvaro's suggestions on generalizing are very helpful and I think will help to clarify these are examples.

Thanks,
Deborah

-----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├╝hlewind's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS)

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>;
Sent: 13 April 2019 17:13
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>;
Cc: 'Mirja K├╝hlewind 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├╝hlewind'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>;
Sent: 13 March 2019 13:16
To: 'Mirja Kuehlewind' <ietf@kuehlewind.net>;
Cc: 'Mirja K├╝hlewind 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├╝hlewind'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
>> 
>> 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.

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