Re: [spring] SRv6 Network Programming and Link Local Source Addresses

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Thu, 19 December 2019 11:51 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 B9FCA1200FE for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=E1BXRpKp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w9lxuiHH
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 xrb7yV50gg_9 for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:51:47 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18741200F9 for <spring@ietf.org>; Thu, 19 Dec 2019 03:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25832; q=dns/txt; s=iport; t=1576756306; x=1577965906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dfSMXNj1qhBMtgpt2jy+8kdfD1kbuTrVQsYwFaK7kZM=; b=E1BXRpKpBfCuDabJNXJ5pw4tvv8+uImuTW+iOMTYavLTXkPEaaiBJhh0 wcZ9rOS0dIl1jsw2i4le+/+k46zYFUd38swmtjkJdQCfcz9KvobHEav8H O6PHKDCG6nmbk5qsYRDftPHdsifxt1NzBU4ZgDUHvWZ44Tci01RrqxYiU c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AcEM01RyOAqxhhJ7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudAkT+JeTrawQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAAACY/td/51dJa1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF8gU1QBWxYIAQLKoQGg0YDinSCX4ldjiqCUgN?= =?us-ascii?q?UCQEBAQwBARgGDwIBAYN7RQIXggQkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQE?= =?us-ascii?q?BAQIBAQEQEREMAQEFJAMLAQsEAgEIDgMBAgEBAQECAiYCAgIfBgsVAgYIAgQ?= =?us-ascii?q?BDQUigwABgkYDDiABDqFSAoE4iGF1gTKCfgEBBS+EcA0LggwDBoEOKIFcij0?= =?us-ascii?q?agUE/gREBJiCCHi4+ghtJAQECgWEHECOCVjKCLI1GgnGPNo5dQwqCNYcxij2?= =?us-ascii?q?EJhuCQ4d5kBWOToFGhwyCHI9jAgQCBAUCDgEBBYFpIoFYcBU7KgGCQVAYDY0?= =?us-ascii?q?SDBeDUIUUhT90AYEnjR0rghQBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,331,1571702400"; d="scan'208";a="396141617"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Dec 2019 11:51:45 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBJBpjHJ026937 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Dec 2019 11:51:45 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 05:51:44 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 05:51:44 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Dec 2019 06:51:44 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RVIpcDVaHu017ju7VZjjsJppn7vUMiURAc3o8+TNdlbHVdm9da+sXS6fn20tNZ0EQkFEN1gL03WVyXZEBOjtfImC9FO1UI8qpmv0mn71Hv0qV03utDKBebkP+yB19xAOk2kXvi25z/AlQ5ny2/p2J+Bjc7C1BnE/s9m214b4x1E6/zZzl0mN6hJmUdASmvvT7eH9KPp4g7RdJe7dw8aXWp7VSc89Y+oMX2VcRihU5zW3EbMOF8ToPQR1AIFGLrmJ/eAUOs5Gg22fxl7v0mWkYQ8i+o/nsZUZED+Y9C6ItNVv18BP1Q2rL6R9n+etsSleVgI3KRI9UOeso09yYW5y6A==
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=dfSMXNj1qhBMtgpt2jy+8kdfD1kbuTrVQsYwFaK7kZM=; b=ihO2pw447cbmSffbgrMX7p8T/Dr8FX1KseAQsuoyt3O5Q0esWQoOJnFW9xqmIaBXlm+gxL+tPR8GQIprioFYLQsP4e/IAFspKpkoM4EEfy7WB1hG6upRy0QnyE7bgf1N8G8rtujYlRQEQomtPOIQiPj1oJyJZvV0bBYSp4uUKZHip3wKK6CgIVVzDN3asbkjL9nI8/HuLt6AgInkWgeY2jz62idTZfKA+W9ewYt04wMZ2l3woT52P5FfQhhDBVXj0fqTUKi940WYUL8HMRCo2Rpvo8eoJzv9fzMm/SvbyfpxxIpRhjm3YDRiAD8M8epeMIRPQkU5VB6ycGvPVg9iZA==
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=dfSMXNj1qhBMtgpt2jy+8kdfD1kbuTrVQsYwFaK7kZM=; b=w9lxuiHHtFmZgWIBL3N5BiIGfEwtVrByd3PzJqgVzK2L0kCosb2G+quhunsO1AybQ2x4NHGfOjGetgo9B8xbP84FyQdFuY/Z2SHNJIxiy5lXNoJsGsh4vpPMlRzOoq6rrfIPeVc4zAs4r4zdkifYd9j0yL6Fh8jwTE2x5DgWBGE=
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:51:43 +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:51:42 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Ron Bonica <rbonica@juniper.net>, "Darren Dukes (ddukes)" <ddukes@cisco.com>
CC: "spring@ietf.org" <spring@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
Thread-Topic: [spring] SRv6 Network Programming and Link Local Source Addresses
Thread-Index: AdWnvRd0lqtmH80YQu+C6Oz5BkM5rgA0iXcAAAHtYYAAAH2owAAAaB+AACLhNsAAAGgsgAAAEqowAMlT84AAAIgLcAClz+aAAACF7UAAbjlSgAAPzKzgAGM7moAAd3bogACH2qeA
Date: Thu, 19 Dec 2019 11:51:42 +0000
Message-ID: <0B39FC3B-8FC5-48A7-AFFB-6540C3CB1CFF@cisco.com>
References: <BN7PR05MB5699A179E7206F3899564234AE410@BN7PR05MB5699.namprd05.prod.outlook.com> <F42D9CF3-DB62-4402-86B6-B48843959A84@gmail.com> <CAO42Z2zv9D7cncX2EfS=Amkbx9cbqNrRytZPdj5YP+h4DsSMGg@mail.gmail.com> <BN7PR05MB5699616A8A4F8DFD876C8352AE400@BN7PR05MB5699.namprd05.prod.outlook.com> <CBB0837B-C743-46A4-86C1-28C96A336E06@gmail.com> <BN7PR05MB5699F8930082179B3B1A28B3AE430@BN7PR05MB5699.namprd05.prod.outlook.com> <1E03C1DB-980A-4BFE-9DCD-56C26BDC8B77@gmail.com> <BN7PR05MB5699E56B4195DBD06F479FB9AE430@BN7PR05MB5699.namprd05.prod.outlook.com> <DDDAFD08-71A1-462E-8C9A-12EDC357B05A@cisco.com> <BN7PR05MB56996E2D298C38271A405B7DAE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <F2CFF352-36D7-42CA-B237-C3B411E6D1E5@cisco.com> <BN7PR05MB56991358B7F9DF89C20B1F44AE580@BN7PR05MB5699.namprd05.prod.outlook.com> <DF6902DF-180E-47F9-AA78-E8357DFE1E97@cisco.com> <BN7PR05MB5699ED782047692908D1B1A5AE5A0@BN7PR05MB5699.namprd05.prod.outlook.com> <FBB4D59D-CCAE-47DE-B867-E25414026B87@cisco.com> <BN7PR05MB569938224165973670A5013BAE510@BN7PR05MB5699.namprd05.prod.outlook.com>
In-Reply-To: <BN7PR05MB569938224165973670A5013BAE510@BN7PR05MB5699.namprd05.prod.outlook.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: e3f2c2f3-ad3f-4b2f-b5bb-08d78479d0f4
x-ms-traffictypediagnostic: BN6PR11MB1955:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN6PR11MB1955DB1FE245E4A04E154B10C9520@BN6PR11MB1955.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(396003)(376002)(51444003)(13464003)(189003)(199004)(316002)(81156014)(8676002)(81166006)(2906002)(186003)(64756008)(66556008)(478600001)(6506007)(110136005)(53546011)(30864003)(6512007)(66476007)(8936002)(66446008)(54906003)(966005)(76116006)(6636002)(5660300002)(4326008)(86362001)(36756003)(91956017)(66946007)(2616005)(6486002)(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: i7MALCJOqnWNluruzp4XYy4GPh+tzj6DN7/arno/1INCXypqUceFcKB3K/xm1QLoiL+xYo+/lEruUbXNHIjnlT19643kkjfFZB83Xr4lsrfqzpEGfSzfDmC6fmHMvCNPFKRD+BGq2n7hu77HEbx2Nt4IPkRJgkMS1rqO/mN4AQ+0exxvdCx/cGo5zX50USafUSl7yqfU5Rcqdik9tIVDEWJxvCcf/DZZgL2AyeIpAbCRhpVPpi1y432MVWBdKOCCJInLEpugtG2ea+asMkhW1Hlf4Gafo6DwX+Gr3hKRl5tVXXQnSegwxVtT5snQqAEffEgM9NuTocigvdiwxr9C8dhqcUdRFwW9L07Rc5N6cC95DI9FDmP9fSKjOXo+cLL9IuH4PLz3b0euk7uEduu8Cb8zNBr1iKb3iIYKqEdntETsRyrfMpwTdKsbxZsmx3D3lJAOd2IPUdHujQOQjs0qJiSPYFLs02h6XMzzxj4PFMzIHwl9wLByUqW1aHGKl0VtIrkwAt77u/TAaNWTjtUh4SvtmBygaFdSHHigt8fgPPdFfmBDbNmsXfcHMtCAx2qJ
Content-Type: text/plain; charset="utf-8"
Content-ID: <E719EFF96BC3D84B95FAD00F06EEF90C@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e3f2c2f3-ad3f-4b2f-b5bb-08d78479d0f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2019 11:51:42.5223 (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: /YFWafmO+z1r8PWCXeoDw9lNJGHJIyBe3OJAYmpzvFIVSE/kRzedl9mp33QmHm3Uw3uCmyhJ85P2GGsm5XQN5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1955
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/SHtrX_At0GMZxwldUubfzqolmAc>
Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
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:51:50 -0000

Thanks Ron for verifying your agreement!  
I think we can make this even simpler by not inventing new text, and relying on the text used in SRH, RFC2460, RFC6554 with a minor tweak to pre-select an egress adjacency.

OLD:
   S15.   Set the packet's egress adjacency to a member of J

NEW:
S15. Resubmit the packet to the IPv6 module for transmission
               to the new destination via a member of J

I have done this update in rev07.

Thanks,
Pablo.

-----Original Message-----
From: Ron Bonica <rbonica@juniper.net>
Date: Monday, 16 December 2019 at 21:40
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, "Darren Dukes (ddukes)" <ddukes@cisco.com>
Cc: SPRING WG <spring@ietf.org>rg>, Bob Hinden <bob.hinden@gmail.com>om>, Mark Smith <markzzzsmith@gmail.com>
Subject: RE: [spring] SRv6 Network Programming and Link Local Source Addresses

    Pablo,
    
    Your point is well-taken. We should remind the reader to abide by *all* RFC 4291 and RFC 8200 validation rules, not just source address validation . I recommend that you make the following change to Section 4.2:
    
    OLD>
    S15.   Set the packet's egress adjacency to a member of J
    <OLD
    
    NEW>
    S15.   Set the packet's egress adjacency to a member of J. Then, validate and transmit the packet. Validation MUST include all rules specified by RFC 4291 and 8200 (e.g., the source address MUST not be multicast or link-local).
    <NEW
    
    The following are some strong reasons for this change:
    
    - In the current text, you select the egress adjacency and stop short. You never say that you are submitting the packet to a forwarding module that validates the packet as per RFCs 4291 and 8200. In fact, you never say that you actually forward the packet at all.
    - Source validation is particularly important. Failure to enforce the above-mentioned rules can leave a network open to security vulnerabilities.
    - It is likely that some readers of this document are routing experts, but not IPv6 experts. A reminder might be appreciated by those who are not IPv6 experts.
    - A strict reading of Section 4.2 suggest that the END.X function might ignore RFC 4291 and RFC 8200 validations. Since the document explores the edges compliance in other places, you probably want to be clear about compliance in Section 4.2.
    
                                                                                                    Happy Holidays,
                                                                                                              Ron
    
    
    Juniper Business Use Only
    
    -----Original Message-----
    From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com> 
    Sent: Saturday, December 14, 2019 5:01 AM
    To: Ron Bonica <rbonica@juniper.net>et>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; Darren Dukes (ddukes) <ddukes@cisco.com>
    Cc: SPRING WG <spring@ietf.org>rg>; Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith <markzzzsmith@gmail.com>
    Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
    
    Ron,
    
    Let's say other RFC defines rules X,Y,Z.
    Draft-ietf-spring-srv6-network-programming follows those RFCs and hence those rules.
    You have a concern that no-one else is sharing on rule Y, and you are asking me to include a reminder saying that Y MUST be followed, but remain silent on X and Z.
    
    What does this mean for X and Z? Does this mean that someone implementing draft-ietf-spring-srv6-network-programming can ignore X and Z? 
    
    Hence, unless you provide a strong reason why such reminder only for Y is needed, I keep my position of agreeing with Bob, Darren and Kamran that such clarification should not be added. Its misleading In my opinion for X and Z. Please provide me an argument or a reason for it.
    
    Thank you,
    Pablo.
    
    -----Original Message-----
    From: Ron Bonica <rbonica@juniper.net>
    Date: Wednesday, 11 December 2019 at 21:37
    To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>, "Darren Dukes (ddukes)" <ddukes@cisco.com>
    Cc: SPRING WG <spring@ietf.org>rg>, Bob Hinden <bob.hinden@gmail.com>om>, Mark Smith <markzzzsmith@gmail.com>
    Subject: RE: [spring] SRv6 Network Programming and Link Local Source Addresses
    
        Pablo,
        
        I am happy to hear that you would not forward the packet. That is the correct behavior.
        
        Could we make that point clear in the draft? 
        
                                                                                 Ron
        
        
        
        Juniper Business Use Only
        
        -----Original Message-----
        From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com> 
        Sent: Wednesday, December 11, 2019 3:07 PM
        To: Ron Bonica <rbonica@juniper.net>et>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; Darren Dukes (ddukes) <ddukes@cisco.com>
        Cc: SPRING WG <spring@ietf.org>rg>; Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith <markzzzsmith@gmail.com>
        Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
        
        Ron,
        
        Ok. Let me try to be open-minded and understand why you have a concern that no-one else is sharing:
        
        I guess that your concern is that since we do not have a second FIB lookup, hence you believe that we would just cross-connect the packet. Is this correct?
        The fact that we set the egress adjacency as part of the End.X pseudocode does not mean that we skip the IPv6 processing, and as part of the IPv6 processing we would not forward such packet.
        
        Thanks,
        Pablo.
        
        -----Original Message-----
        From: Ron Bonica <rbonica@juniper.net>
        Date: Tuesday, 10 December 2019 at 00:03
        To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>, "Darren Dukes (ddukes)" <ddukes@cisco.com>
        Cc: SPRING WG <spring@ietf.org>rg>, Bob Hinden <bob.hinden@gmail.com>om>, Mark Smith <markzzzsmith@gmail.com>
        Subject: RE: [spring] SRv6 Network Programming and Link Local Source Addresses
        
            Pablo,
            
            Let us agree to disagree.
            
            Chairs,
            
            Please do not close this issue.
            
                                      Ron
            
            
            
            Juniper Business Use Only
            
            -----Original Message-----
            From: spring <spring-bounces@ietf.org> On Behalf Of Pablo Camarillo (pcamaril)
            Sent: Monday, December 9, 2019 10:16 AM
            To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; Darren Dukes (ddukes) <ddukes@cisco.com>
            Cc: SPRING WG <spring@ietf.org>rg>; Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith <markzzzsmith@gmail.com>
            Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
            
            Ron,
            
            I agree with Bob, Darren and Kamran that the existing IPv6 processing rules are followed in Network Programming and do not need to be re-stated.
            
            Cheers,
            Pablo.
            
            -----Original Message-----
            From: spring <spring-bounces@ietf.org> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
            Date: Friday, 6 December 2019 at 17:17
            To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
            Cc: SPRING WG <spring@ietf.org>rg>, Bob Hinden <bob.hinden@gmail.com>om>, Mark Smith <markzzzsmith@gmail.com>
            Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
            
                Darren,
                
                If the draft adhered strictly to RFC 4291 and RFC 8200 in all other respects, I would agree with you and Bob. However, it doesn't.
                
                As it stands, the reader is left to guess when the draft adheres to previous specifications, but doesn't say so explicitly, and when it is taking liberties with previous specifications.
                
                                                                                               Ron
                
                
                
                
                Juniper Business Use Only
                
                -----Original Message-----
                From: Darren Dukes (ddukes) <ddukes@cisco.com> 
                Sent: Friday, December 6, 2019 10:53 AM
                To: Ron Bonica <rbonica@juniper.net>
                Cc: Bob Hinden <bob.hinden@gmail.com>om>; SPRING WG <spring@ietf.org>rg>; Mark Smith <markzzzsmith@gmail.com>
                Subject: Re: [spring] SRv6 Network Programming and Link Local Source Addresses
                
                Hi Ron, I agree with Bob here.
                
                Section 4.2 pseudocode simply says an implementation would use a predetermined egress adjacency instead of performing a FIB lookup to find one.  
                It specifies the SID processing, not the entire IPv6 data path.
                
                It has no text that would indicate RFC4291 text on link-local addresses and routers would not apply.
                
                As a side note, every routing header currently defined (even those now deprecated) do not re-state the RFC4291 text.
                
                Thanks,
                  Darren
                
                
                > On Dec 2, 2019, at 10:58 AM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
                > 
                > Bob,
                > 
                > Before we debate presentation too much, we should let Pablo answer the original question. Will the packet be dropped or forwarded?
                > 
                > If the packet will be dropped, how is the reader of Section 4.2 to know this? Normally, pseudocode is taken literally, and the pseudocode in Section 4.2 suggests that the packet will be forwarded.
                > 
                > One way to wiggle out of this problem is to include a sentence at the beginning of Section 4 saying, "When the following pseudocode contradicts RFC 4291 or 8200, RFCs 4291 and 8200 take precedence.
                > 
                >                                                                                                              
                > Ron
                > 
                > 
                > 
                > 
                > Juniper Business Use Only
                > 
                > -----Original Message-----
                > From: Bob Hinden <bob.hinden@gmail.com>
                > Sent: Monday, December 2, 2019 10:47 AM
                > To: Ron Bonica <rbonica@juniper.net>
                > Cc: Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith 
                > <markzzzsmith@gmail.com>om>; SPRING WG <spring@ietf.org>
                > Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
                > Addresses
                > 
                > Ron,
                > 
                >> On Dec 2, 2019, at 7:36 AM, Ron Bonica <rbonica@juniper.net> wrote:
                >> 
                >> Bob,
                >> 
                >> Take a look at Section 4.2. The pseudocode is pretty specific.
                > 
                > Please explain.  I don’t see that.
                > 
                > Thanks,
                > Bob
                > 
                > 
                >> 
                >>                                           Ron
                >> 
                >> 
                >> 
                >> Juniper Business Use Only
                >> 
                >> -----Original Message-----
                >> From: Bob Hinden <bob.hinden@gmail.com>
                >> Sent: Sunday, December 1, 2019 5:56 PM
                >> To: Ron Bonica <rbonica@juniper.net>
                >> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Mark Smith 
                >> <markzzzsmith@gmail.com>om>; SPRING WG <spring@ietf.org>
                >> Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
                >> Addresses
                >> 
                >> Ron,
                >> 
                >>> On Dec 1, 2019, at 2:47 PM, Ron Bonica <rbonica@juniper.net> wrote:
                >>> 
                >>> Mark, Bob,
                >>> 
                >>> Yes, I agree that routers should not forward packets with link local source addresses.
                >> 
                >> or Destination addresses.
                >> 
                >>> 
                >>> Pablo,
                >>> 
                >>> Maybe we should update section 4.2 of the network programming draft to reflect this?
                >> 
                >> I was thinking that unless network programming has text that might cause one to think it overrides the defined behavior from rfc4291 for link-local addresses, I am not sure it has to be mentioned.
                >> 
                >> Bob
                >> 
                >> 
                >>> 
                >>>                                                                Ron
                >>> 
                >>> 
                >>> From: Mark Smith <markzzzsmith@gmail.com>
                >>> Sent: Sunday, December 1, 2019 5:31 PM
                >>> To: Bob Hinden <bob.hinden@gmail.com>
                >>> Cc: Ron Bonica <rbonica@juniper.net>et>; SPRING WG <spring@ietf.org>
                >>> Subject: Re: [spring] SRv6 Network Programming and Link Local Source 
                >>> Addresses
                >>> 
                >>> 
                >>> 
                >>> On Mon, 2 Dec 2019, 08:35 Bob Hinden, <bob.hinden@gmail.com> wrote:
                >>> Ron,
                >>> 
                >>>> On Nov 30, 2019, at 12:36 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
                >>>> 
                >>>> Pablo,
                >>>> 
                >>>> 
                >>>> 
                >>>> Consider the packet (SA,DA) (S3, S2, S1; SL) where:
                >>>> 
                >>>> 
                >>>> 
                >>>>     • SA is link-local (fe80)
                >>>>     • DA, S3, S2, and S1 are all END.X
                >>>> 
                >>>> 
                >>>> Section 4.2 suggests that this packet will be delivered over multiple hops to its destination, regardless of its link-local source address.
                >>> 
                >>> I would think that RFC2460 Section 2.5.6. "Link-Local IPv6 Unicast Addresses” covers this:
                >>> 
                >>>  Link-Local addresses are for use on a single link.  Link-Local  
                >>> addresses have the following format:
                >>> 
                >>>  |   10     |
                >>>  |  bits    |         54 bits         |          64 bits           |
                >>>  +----------+-------------------------+----------------------------+
                >>>  |1111111010|           0             |       interface ID         |
                >>>  +----------+-------------------------+----------------------------+
                >>> 
                >>>  Link-Local addresses are designed to be used for addressing on a  
                >>> single link for purposes such as automatic address configuration,  
                >>> neighbor discovery, or when no routers are present.
                >>> 
                >>>  Routers must not forward any packets with Link-Local source or  
                >>> destination addresses to other links.
                >>> 
                >>> I think that's RFC4291.
                >>> 
                >>> RFC4007, "IPv6 Scoped Address Architecture" does too, more generally and probably more formally, in particular section 9, "Forwarding".
                >>> 
                >>> Regards,
                >>> Mark.
                >>> 
                >>> 
                >>> 
                >>> Bob
                >>> 
                >>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> Is this the case?
                >>>> 
                >>>> 
                >>>> 
                >>>>                                                            Ron
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> 
                >>>> Juniper Business Use Only
                >>>> _______________________________________________
                >>>> spring mailing list
                >>>> spring@ietf.org
                >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/s
                >>>> pring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1
                >>>> fsLwpCkacVdsltFrrl$
                >>> 
                >>> _______________________________________________
                >>> spring mailing list
                >>> spring@ietf.org
                >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
                >>> ring__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fs
                >>> LwpCkacVdsltFrrl$
                >>> 
                >>> Juniper Business Use Only
                > _______________________________________________
                > spring mailing list
                > spring@ietf.org
                > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
                > ng__;!8WoA6RjC81c!X0Mi1EMDcUpqGxHLkmQkX30EHTgzVWkxOQTTSCO1ZK60Y1fsLwpCkacVdsltFrrl$
                _______________________________________________
                spring mailing list
                spring@ietf.org
                https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$ 
                
            
            _______________________________________________
            spring mailing list
            spring@ietf.org
            https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S9ht1iKevwXKxhNLJwPAOviqxEttD_Ij3orL76Tjf6j0zxxgxMKwhMJ8iuT8hyc0$