Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Thu, 19 December 2019 11:53 UTC

Return-Path: <pcamaril@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B75412010C for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LFn4wZX6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Fyl08P5x
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 EYqEV3Nc1Up4 for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:53:35 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00541120106 for <spring@ietf.org>; Thu, 19 Dec 2019 03:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12760; q=dns/txt; s=iport; t=1576756414; x=1577966014; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=On2YsgWLNwfbDAsACQDUeUW8Quz+P1jUT8Z1GEWIa+I=; b=LFn4wZX6K8v3AY6+FtMh3qH/tpbe1JcFSWl6mRGwLxRvgn/a6cK47OCX DjcCcldvRbDVe0vyXy1ij2vCS5w5h6lqIRRJy46Kspe350BQaZnSKeFv3 cxFQAuc8NA6zejWHYG+TY6Nc5yx+q7NtNrybHyTuIp1wVk0j6t6mbIzBX U=;
IronPort-PHdr: =?us-ascii?q?9a23=3AFmTj1hC8j2OVwRSQSA71UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNPXjaiUgHcBqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLCQB9Y/td/4UNJK1eBhwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF8gU1QBWxYIAQLKoQGg0YDinNOgWwliV2OKoFCgRADVAkBAQE?= =?us-ascii?q?MAQEYDQgCAQGDe0UCF4IEJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQE?= =?us-ascii?q?BEBERDAEBLAwLBAIBCBEDAQIBAgImAgICHwYLFQgIAgQBEgkZgwABgkYDDiA?= =?us-ascii?q?BDqFRAoE4iGF1gTKCfgEBBYE1AQMCDkFAglUNC4IMCYEOKIwZGoFBP4ERJww?= =?us-ascii?q?Ugkw+ghs+CwEBAQEBARiBLwoOgxAygiyNTYJqjzaOXUMKgjWHMYldBlqEJhu?= =?us-ascii?q?CQ3WHBJAVjk6BRocMghyCfYxmAgQCBAUCDgEBBYFpIoFYcBUaISoBgkEJRxg?= =?us-ascii?q?Nig2DBYNzhRSFP3QBAYEmj1wBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,331,1571702400"; d="scan'208";a="690559722"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Dec 2019 11:53:33 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xBJBrXoI017274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Dec 2019 11:53:33 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 05:53:32 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 06:53:32 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Dec 2019 05:53:31 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UanpuIkPns1oqPhT7zkDBQJi48aze4sYeBg+pwHooXvrJ2OfhXzZ05JOPhYscHi41RhZ2NGVYYTv65biNsbzEEUtocpvueuFt7MCpxyoxcCE1/R3OAxTVkJ1tvymr55wrABzmz1Hp5dZJtzRmjZZOGqG9um85NaqolSbEhM/F+FnlqwfcIJLwKJxNShDxeXx8yyxYaenVqMxTH0UACMzMExcv2GIUnBUhJG9H+KHFLio2H0Vt3Pry0BrYPw8Fs8VrPX1SQZoFiglfLVF50CfafwAU6rTbAMKOh4fw0hD9Segnrt48F0hD1GlW2kvyfE6jCOqFl+1RWDigdO9PPuBmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=On2YsgWLNwfbDAsACQDUeUW8Quz+P1jUT8Z1GEWIa+I=; b=D2SMs+9pB6rS2itOxDbJvkBskyPCYBBghECZNUlZhQQjFnm4A/iAifwQaVRmi97aYQMgshYYgRKsa/VVLopAb1hG14UGMlxFbIhOxU99OuihypZ0ZwIT7CvEUdNkAwm4NsJMP3tvaH8aSWVenhUcCnknLUmo5I/T2L7VXqvNjhf5LVH4mGmISo+/XeeueJ0Asd0s+Bn8hA1vqaA3B+9V8xfwmSyWbbkBVsLTtGNrwOEDJob58uJSPe+uY8nnHL+b8ItryTUUm/UmAC9WXn9MUUuUDaU3wh8zfzwhOojbrWOQ1eZQVhaasVS1m1xKKjhprFBpPi3fjMcyML5AV+ZniQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=On2YsgWLNwfbDAsACQDUeUW8Quz+P1jUT8Z1GEWIa+I=; b=Fyl08P5xgAtO8Gxb47BEOXqXANcRE6Cc68db4M8iGHNMCBLqQJnloOELWRIciohM46h5rCDfKFCFCgysPMxjKyqon1vZniqkxDWWROvC4VJMUO9pAVME8PipKYJsV8xF41+6pLP1R9T6kjz6rXAHP0gqRS3Zra3Tk8zptCf+sow=
Received: from BN6PR11MB1363.namprd11.prod.outlook.com (10.173.33.7) by BN6PR11MB1955.namprd11.prod.outlook.com (10.175.98.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Thu, 19 Dec 2019 11:53:30 +0000
Received: from BN6PR11MB1363.namprd11.prod.outlook.com ([fe80::3113:31:4a84:cc4d]) by BN6PR11MB1363.namprd11.prod.outlook.com ([fe80::3113:31:4a84:cc4d%6]) with mapi id 15.20.2559.016; Thu, 19 Dec 2019 11:53:30 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
Thread-Index: AQHVsFzuMqEE0m+BQku/EkspZFszBae1fbKAgAP1rwCAAJ9GAIACcpCA
Date: Thu, 19 Dec 2019 11:53:30 +0000
Message-ID: <ACEF56BF-B851-43B2-9211-B6C39C34DB63@cisco.com>
References: <157609408568.11496.11799785813274132900@ietfa.amsl.com> <4c762fc5-8a61-e182-a9cc-d45b0f586ccc@gmail.com> <3A12D735-7899-4679-8FC8-DF8875D40A62@cisco.com> <628e5dfb-7ba4-d841-ebeb-cfc52d7294f1@gmail.com>
In-Reply-To: <628e5dfb-7ba4-d841-ebeb-cfc52d7294f1@gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.20.0.191208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [2001:420:44da:1250:2dac:e1f3:236d:5679]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 50a9b029-2a39-441c-0830-08d7847a1140
x-ms-traffictypediagnostic: BN6PR11MB1955:
x-microsoft-antispam-prvs: <BN6PR11MB1955015F19C7CEFCB60B180EC9520@BN6PR11MB1955.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(396003)(376002)(51914003)(13464003)(189003)(199004)(316002)(81156014)(8676002)(81166006)(2906002)(186003)(64756008)(66556008)(478600001)(6506007)(110136005)(53546011)(6512007)(66476007)(8936002)(66446008)(966005)(76116006)(5660300002)(86362001)(4001150100001)(36756003)(91956017)(66946007)(2616005)(6486002)(66574012)(71200400001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1955; H:BN6PR11MB1363.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7BRcqACLK11eTBIiWjU6SrozByxmHoxV83IoZCKM9RHPU6I2Kz07261Q1KEutXTzW0K/blYwKEPzqdfdYUMQMEUpo/VOXPr3kLHgNy3RTcfiyvajoOuieIXUKBF9Englxx6s2QNyQf1MgnnzVUiRXvOzq2nil7B8yvnv8XYatPUBOkaatQ7eFv1r7FO65uL0kXL0wy3tthK1gb81CpZJKS910uraZ7qQqSHH14oGb0faZI2epDmNiM6XiyrWheVjL2IffhHY4OLkJPb0kxJZe6FiC5NxOyEJKv++IstvQA3GSBW3sqFmml+A06FMP3td1C/dEZMV7uYAcZAaBI7zVSBfFMzrvnC2ICjaAgw5sUnqS5Jpx/U4+bGF0sTzJMmQCsDDZpjIpZ/J/o8v102l8m9JXRtH2mSpvvLlfU31idWhu4rcMS4E0THLaBNrj1u+7zb9f5OvSGhUZmew7GgdsKuA6sZFl3Oh5E4KzA8EJf0/gONmuM+cctT60QhrdDhcumwxGPQENVGiI7R9FUE0lESoiWuiVu1jdT4uTBovMbE+eSHCMYkSYRm+1y2h1WfB
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A47A23D40ABED245ACE2CC807FF47348@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 50a9b029-2a39-441c-0830-08d7847a1140
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2019 11:53:30.3201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IMu6feSVPgEjpwiuNv8DUOC4+h/hwIfghnAjVFZQA4j31AmYgxX9HAbnuMGQxlqF9KKFNQ0Y8HbNlSdamYLbuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1955
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/mXcsWXaISqjzs7g_fJZYhcKabgY>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 11:53:37 -0000

Brian,

Inline.

Thank you,
Pablo.

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Saturday, 14 December 2019 at 21:04
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

    Hi Pablo,
    
    See in line:
    
    On 14-Dec-19 22:34, Pablo Camarillo (pcamaril) wrote:
    > Brian,
    > 
    > Many thanks for having another look to the draft. Please see inline [PC].
    > 
    > Thank you,
    > Pablo.
    > 
    > -----Original Message-----
    > From: spring <spring-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
    > Date: Wednesday, 11 December 2019 at 23:06
    > To: "spring@ietf.org" <spring@ietf.org>
    > Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
    > 
    >     So, I've tried to look at this with fresh eyes, and thanks for the
    >     various updates and clarifications.
    >     
    >     (I'm still not on the SPRING list so please leave me in CC.)
    >     
    >     I remain a bit puzzled. First, a quote from the SRH specification
    >     (draft-ietf-6man-segment-routing-header-26):
    >     
    >     > 4.2.  Transit Node
    >     > 
    >     >    As specified in [RFC8200], the only node allowed to inspect the
    >     >    Routing Extension Header (and therefore the SRH), is the node
    >     >    corresponding to the DA of the packet.  Any other transit node MUST
    >     >    NOT inspect the underneath routing header and MUST forward the packet
    >     >    toward the DA according to its IPv6 routing table.
    >     
    >     Next, a quote from the current draft:
    >     
    >     >    SRH[n]: A shorter representation of Segment List[n], as defined in
    >     >    [I-D.ietf-6man-segment-routing-header].
    >     > 
    >     >    When a packet is intercepted on a wire, it is possible that SRH[SL]
    >     >    is different from the DA.
    >     
    >     Huh? That would be extremely unusual in the normal interpretation
    >     of a routing header, where is RH[SL] is by definition the next
    >     destination where the RH will be processed. Any other node is a transit
    >     node, and I don't see anything in draft-ietf-6man-segment-routing-header-26
    >     that allows for anything else. So it seems to me that the quoted statement
    >     needs an explanation of why it isn't a violation of
    >     draft-ietf-6man-segment-routing-header-26, not to mention why it's useful.
    > 
    > PC: This occurs when we use the reduced SRH as described in: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1

    OK, well that definitely needs to be added to the draft, since it is very far from
    obvious to a newcomer.

PC: I have removed this sentence from the latest revision of the draft. Unneeded, misleading and covered in the SRH. See rev07. Thank you for your comment.

    > If you think this sentence does not reflect that, I can edit it for the next revision of the draft. 
    >     
    >     That leads us back to:
    >     
    >     > 4.16.1.  PSP: Penultimate Segment Pop of the SRH
    >     > 
    >     >    The SRH processing of the End, End.X and End.T behaviors are
    >     >    modified: after the instruction "S14.  Update IPv6 DA with Segment
    >     >    List[Segments Left]" is executed, the following instructions must be
    >     >    executed as well:
    >     > 
    >     >  S14.1.   If (Segments Left == 0) {
    >     >  S14.2.      Update the Next Header field in the preceding header to the
    >     >                 Next Header value of the SRH
    >     >  S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
    >     >                 value of the SRH
    >     >  S14.4.      Remove the SRH from the IPv6 extension header chain
    >     >  S14.5.   }
    >     
    >     This is clearly a breach of RFC8200, but it can never be reached if DA == SRH[SL]. 
    
    > PC: PSP executes at the segment that is the Destination Address.
    
    I am probably being stupid, but I don't understand what is "penultimate" about
    a condition where SL == 0 and the packet has reached the node that owns DA.
    Where will the packet be sent next, since it's already at the final DA?

PC: You are reading line 14 of a pseudocode. In the previous lines we have received a packet with Segments Left = 1, and we have decremented by one such value.
    
    (The example at
    https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-01#section-2.8.1
    doesn't help me in the least. Is there a conceptual discussion of the purpose
    of PSP?)
    
    If the packet is to be forwarded again, "Remove the SRH from the IPv6
    extension header chain" violates RFC 8200, as does "Decrease the IPv6 header
    Payload Length by the Hdr Ext Len value of the SRH".

PC: The node that executes the PSP behavior is identified in the IPv6 Destination Address of the packet. This does not violate RFC8200.
    
    This objection doesn't seem to arise for USP, since presumably at that point
    the packet has reached the final DA and any mangling is internal to the host.
      
    >     The operation "4.16.2.  USP: Ultimate Segment Pop of the SRH" seems like
    >     a pointless variant on "4.16.3.  USD: Ultimate Segment Decapsulation", 
    >     since the packet has reached its destination anyway and will presumably
    >     be decapsulated anyway. 
    > 
    > PC: This has already been discussed in the past in the SPRING mailer. https://mailarchive.ietf.org/arch/msg/spring/Q3MYlGDQs5MO-dOFOZJUx2hHni4
    
    Yes, OK, the offload NIC as a use case is reasonable. As far as the network
    is concerned, that is internal to the host. But some hint about the purpose
    and value of these features is needed in the draft, IMHO.
    
    Regards
        Brian
    
    
    >     
    >     Regards
    >        Brian Carpenter
    >     
    >     On 12-Dec-19 08:54, internet-drafts@ietf.org wrote:
    >     > 
    >     > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >     > This draft is a work item of the Source Packet Routing in Networking WG of the IETF.
    >     > 
    >     >         Title           : SRv6 Network Programming
    >     >         Authors         : Clarence Filsfils
    >     >                           Pablo Camarillo Garvia
    >     >                           John Leddy
    >     >                           Daniel Voyer
    >     >                           Satoru Matsushima
    >     >                           Zhenbin Li
    >     > 	Filename        : draft-ietf-spring-srv6-network-programming-06.txt
    >     > 	Pages           : 39
    >     > 	Date            : 2019-12-11
    >     > 
    >     > Abstract:
    >     >    The SRv6 Network Programming framework enables a network operator or
    >     >    an application to specify a packet packet processing program by
    >     >    encoding a sequence of instructions in the IPv6 packet header.
    >     > 
    >     >    Each instruction is implemented on one or several nodes in the
    >     >    network and identified by an SRv6 Segment Identifier in the packet.
    >     > 
    >     >    This document defines the SRv6 Network Programming concept and
    >     >    specifies the base set of SRv6 behaviors that enables the creation of
    >     >    interoperable overlays with underlay optimization (Service Level
    >     >    Agreements).
    >     > 
    >     > 
    >     > The IETF datatracker status page for this draft is:
    >     > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
    >     > 
    >     > There are also htmlized versions available at:
    >     > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-06
    >     > https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-06
    >     > 
    >     > A diff from the previous version is available at:
    >     > https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-06
    >     > 
    >     > 
    >     > Please note that it may take a couple of minutes from the time of submission
    >     > until the htmlized version and diff are available at tools.ietf.org.
    >     > 
    >     > Internet-Drafts are also available by anonymous FTP at:
    >     > ftp://ftp.ietf.org/internet-drafts/
    >     > 
    >     > _______________________________________________
    >     > I-D-Announce mailing list
    >     > I-D-Announce@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/i-d-announce
    >     > Internet-Draft directories: http://www.ietf.org/shadow.html
    >     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    >     > 
    >     
    >     _______________________________________________
    >     spring mailing list
    >     spring@ietf.org
    >     https://www.ietf.org/mailman/listinfo/spring
    >     
    >