Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Wed, 11 March 2020 18:44 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 875F13A111D for <spring@ietfa.amsl.com>; Wed, 11 Mar 2020 11:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=Ju+Gj0QI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gh1xKSL5
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 1i56z1nmyPzu for <spring@ietfa.amsl.com>; Wed, 11 Mar 2020 11:44:48 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63DF3A111C for <spring@ietf.org>; Wed, 11 Mar 2020 11:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14118; q=dns/txt; s=iport; t=1583952269; x=1585161869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AoQE3DMj4ZKZJpRyO9poai1BmBPRtMHzrWtnGaW1Y9s=; b=Ju+Gj0QIpIdk+LKJY4drMVVevO3JCrBHJcpck2nZQXrjzn/xJ4CF3PvO kdqnXmSR4NvRK99bQxAQDmdBxJM0+5nmhesn8CyaKjHQl1qRaDP0IUkdX 86n2RQj55lQ4/ZYLyiHriJvZxJJTd8s5d/WFPdRSXfeMBdZA1eE2Sk3M2 E=;
IronPort-PHdr: 9a23:quNoqhGGMqyyVUObUrIz0Z1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eebhZikzBsVGfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C0AAAiMWle/5FdJa1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKgqEC4NFA4ptgjolgQGXFIJSA1QJAQEBDAEBGA0IAgQBAYN+RQIXgXYkOBMCAwEBCwEBBQEBAQIBBQRthVYMhWMBAQEBAgEBARAREQwBASwLAQsEAgEIDgMDAQIBAgImAgICJQsVCAgCBA4FIoMEAYJKAw4gAQ6gGwKBOYhidYEygn8BAQWCRIJVGIIMCYEOKowsGoFBP4ERJwwUghg1PoJkAQECAYE6KIMRMoIsjWISgneeUXYKgjyHVYVNiUkdmzqXepJWAgQCBAUCDgEBBYFpIoFYcBU7KgGCQQlHGA2OHQwXglCBAIUUhUF0AoEninOBMgGBDwEB
X-IronPort-AV: E=Sophos;i="5.70,541,1574121600"; d="scan'208";a="460287972"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2020 18:44:28 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 02BIiSnM015453 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Mar 2020 18:44:28 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Mar 2020 13:44:28 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Mar 2020 13:44:27 -0500
Received: from NAM04-CO1-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; Wed, 11 Mar 2020 13:44:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HmXPvBolTK4T2KIJhmydnrNuaqxNGTIgPWknWbXwfsGx4RRttFgCTq0bCQRtogqwwyxpUhN9YZGg50urFX6P+kJfYemKaPwszEOzDbtHGlYi1QiPIjP6s84aDI6v5SJeHaekFyJlOrKaBYCP9PNeWle9ULRDAu6fFg2dyVgaFC/bQxtqq6cCWi6h5uH9AifGLICZi7/FlvdtOhUnkJyJGjCIX9KYdM+5vJcVC/nWjB60RftY2kneKQ7oR3V4NcA4IAniWJvCXJLHjPJFN5rTp8pAaFBiR5VfjOzc8iVjYo8J3Ln9MNabTC7YE2SAUuosScs4uAnuzZpUtTZOUxhN5g==
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=AoQE3DMj4ZKZJpRyO9poai1BmBPRtMHzrWtnGaW1Y9s=; b=LGWrEiJzNTo8PNktzwi8zJyHPMfaaFzAA7LO3SarNLrsG6n1basvBoa84gSPC2sV/wc3gMhbG+X18cRGpWSjKNRPicgU2KDLkAeUfbLoEzhqCu6tBKL9ebfWzaNZyO6RsRrRvsrx/CyIPqSnfIVkj/+u7/2NMASIfV7LC2y8vPlxv8y1hZFBNXWxTfHH57UD96PsGhG0V2MFEW8JjOfHe0Sbq3m1/SnLbNnjeKPGS+9lqFsvskBgBQ5QIBiIKNkZIVMDe3z42R51mlguHO/df14IB5+UKL0tkFXci+BmknpgofFE9k5dHSjkEXqko4pS0dQNqbxU3ObFGpFFxXC82w==
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=AoQE3DMj4ZKZJpRyO9poai1BmBPRtMHzrWtnGaW1Y9s=; b=Gh1xKSL5s4Xa0BNSF4WnLd6f/1V9rElfV+PvYKrEkzkgNFz661yHlGQ0/yyrRINSqJGZlAKhSNOyIla200o8Y/WCvC4Ua/UO/HR/02+ZDUhjywgbIQGzNUuNbXmq/OTCeOSwb75KkkWu0qW6vj79K3l0ZwTGLDDpfET4btbZd5Y=
Received: from DM5PR11MB1370.namprd11.prod.outlook.com (2603:10b6:3:9::7) by DM5PR11MB1722.namprd11.prod.outlook.com (2603:10b6:3:f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Wed, 11 Mar 2020 18:44:26 +0000
Received: from DM5PR11MB1370.namprd11.prod.outlook.com ([fe80::50e4:48e0:19e4:9cc9]) by DM5PR11MB1370.namprd11.prod.outlook.com ([fe80::50e4:48e0:19e4:9cc9%12]) with mapi id 15.20.2793.018; Wed, 11 Mar 2020 18:44:26 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Christian Hopps <chopps@chopps.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Question on draft-ietf-spring-srv6-network-programming-12
Thread-Index: AQHV9HaX6Lkkq5pSPUGuGY0sidbPhahCNwoAgAAeNgCAAOn9AIAAAhCAgAAkXQCAAC/KgIAAPI6A
Date: Wed, 11 Mar 2020 18:44:26 +0000
Message-ID: <A053B5E0-ECB3-42E8-9740-12B87DB0749B@cisco.com>
References: <D5A410FF-EEA3-4F01-8147-5E180EE35DE6@chopps.org> <A6B1D2E0-0230-468B-931F-C6C976BDC9DC@cisco.com> <84B6A844-0811-4317-8EC5-A204B2B23F23@chopps.org> <81EA92B2-5057-43F3-A895-53B08FB0D746@cisco.com> <7DDFB2C3-4C7D-4750-8B4B-8D96532B6A6D@chopps.org> <BD09DFAC-1A16-41F8-B204-38D98AA38050@cisco.com> <1114E167-1853-4004-A42F-E4F1185CB296@chopps.org>
In-Reply-To: <1114E167-1853-4004-A42F-E4F1185CB296@chopps.org>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [173.38.220.60]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d755a08b-6591-4229-9416-08d7c5ec39c9
x-ms-traffictypediagnostic: DM5PR11MB1722:
x-microsoft-antispam-prvs: <DM5PR11MB17222D7086B385854F7DC8CAC9FC0@DM5PR11MB1722.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0339F89554
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(39860400002)(396003)(376002)(199004)(8676002)(71200400001)(8936002)(66446008)(36756003)(66476007)(86362001)(64756008)(316002)(66946007)(4326008)(966005)(186003)(66556008)(6486002)(66574012)(478600001)(6916009)(6506007)(53546011)(2616005)(6512007)(91956017)(81166006)(26005)(2906002)(5660300002)(33656002)(76116006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1722; H:DM5PR11MB1370.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: RRnjZ+M/+qSLZ+O/NAGbR14cvO1yrg0Q21Mw1rb9u+F/7I3sszbZzpS99YMrqukwRJVNueZHxZy1/oIdLyyJdX+u0bKy2sohQKw0h+JQRsV8VNxPEL3WbhQAxW7dlf6azVnJ1z2dTTK+JBnLZovIO/0+hB03xLz1LPZB3HbliaBykUCdjOSNKVIC6wSiC5SEfbJdjcnKzr8Df/tc9hYtI9Ep2F2bDZOEheq8NtvU7zKSzEP12UOmJi4fqMteBxlX0T9C9OW0VkDseEVntGM0kCdUdVmHQyCzhsQGNxoYIGYnDcHUADHcEwYpeo7Ffr9GMVYgR13tVXPg6WbZbAqMGEwJkCcurJyEn3Yu2GMvJUvsjkP0638RSxenew8XDhnKV1bWBd/HrIfgUx+8H2SGAo6xg61Ih07OgcLaVuXmD35lKnYgCsAk0I1bF0SpaHhEirLSTpu6l75V6fuOUPQE6177qg+cp4kH4a9+PQO+ZSASFO+dcnMKzCHyKsjWFKxws1edR32OTMZCDJLBI/RGnA==
x-ms-exchange-antispam-messagedata: TZL0zY27uOk5JN0bIgX9Yw8SuDOQUiC8DX9sSQ09ypOugySmw5n3u2dYRDoBD3S3DjwRdG466vb9LPdV49D7UgO7jSHNhHsVfaUDzxyqsajoNl1DRVS6YdfxbjZ6yhAWUwoSNzUzOuwAbHaAGWaRig==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A7001BF8510CCC4484E7B6EC336EB34C@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d755a08b-6591-4229-9416-08d7c5ec39c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 18:44:26.4102 (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: qp4ldECOh2SlXE2OXIXnRmmKJUVGO+JndJAv15VbGXdvjNJ27ZaJ5dn6jYkeMGjSviRaxUDuClp4VmieY9Frmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1722
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XcUHCOArq1B8tsrKyzMFyDEtvWQ>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12
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: Wed, 11 Mar 2020 18:44:51 -0000

Hi Chris,

Indeed, an IPv6 packet with no SRH (and FIB entry is local End SID) is one way to get to the Upper Layer Header processing defined in 4.1.1.
Another way is to have a FIB entry bound to an End.DT* or End.DX* behavior. In these cases the ULH processing occurs if the SRH has SL=0 or there's no SRH.

Many thanks,
Pablo.

-----Original Message-----
From: Christian Hopps <chopps@chopps.org>
Date: Wednesday, 11 March 2020 at 17:08
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

    
    
    > On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org> wrote:
    > 
    > Hi Chris,
    > 
    > The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH. 
    > Particularly see https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.3
    > 
    >> Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it?
    > 
    > It is not *only* covering that case (although that is one of the cases, there are others). You process the extension header chain as defined in RFC8200.
    
    Right I had quoted the 8200 processing order so I'm using that as a guide.
    
    > When processing the SRH you follow the processing of 4.1; If you get to the Upper Layer Header, you process it as per 4.1.1
    
    This is what I'm getting at though, if there is an SRH you will enter section 4.1 prior to 4.1.1, and if you are in 4.1 there is no processing path that leads to the upper-layer header. So AFAICT the only way to get to section 4.1.1 is if the FIB entry is a local END SID and there is no SRH.
    
    Thanks,
    Chris.
    
    > 
    > Thank you,
    > Pablo. 
    > 
    > -----Original Message-----
    > From: Christian Hopps <chopps@chopps.org>
    > Date: Wednesday, 11 March 2020 at 12:06
    > To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
    > Cc: Christian Hopps <chopps@chopps.org>, "spring@ietf.org" <spring@ietf.org>
    > Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12
    > 
    > 
    > 
    >> On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org> wrote:
    >> 
    >> Hi Chris,
    >> 
    >> They are the same thing. 
    > 
    >    Ok, so how do I get on 2 different processing paths for the same thing entry as Section 4.1 cannot lead to processing of an upper-layer header as far as I can tell, yet section 4.1.1 is talking about processing the upper layer header for the same FIB entry.
    > 
    >    1) Packet arrives, FIB lookup on packet destination address returns local End SID entry.
    > 
    >    2) Start processing the extension headers and arrive at the SRH (which comes prior to the upper-layer header.
    > 
    >       From RFC8200 the extension header order:
    >          IPv6 header
    >          Hop-by-Hop Options header
    >          Destination Options header (note 1)
    >          Routing header <------------------------------------ SRH
    >          Fragment header
    >          Authentication header (note 2)
    >          Encapsulating Security Payload header (note 2)
    >          Destination Options header (note 3)
    >          Upper-Layer header <-------------------------------- Upper Layer Header
    > 
    >    3) Process the SRH according to 4.1 for which there is no exit that leads to processing any more headers.
    > 
    >    Oh wait...
    > 
    >    Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it? If this is the case then it would make things *way* more clear for the document to state this outright. "When a packet's DA returns a FIB entry for a local END SID, but the packet does not contain an SRH ..." or something like that.
    > 
    >    Thanks,
    >    Chris.
    > 
    > 
    >> 
    >> Section 3:
    >>  ...
    >>  Its processing is defined in [I-D.ietf-6man-segment-routing-header]
    >>  section 4.3 and reproduced here as a reminder.
    >> 
    >>     Without constraining the details of an implementation, the SR
    >>     segment endpoint node creates Forwarding Information Base (FIB)
    >>     entries for its local SIDs.
    >> 
    >>     When an SRv6-capable node receives an IPv6 packet, it performs a
    >>     longest-prefix-match lookup on the packets destination address.
    >>     This lookup can return any of the following:
    >> 
    >>     - A FIB entry that represents a locally instantiated SRv6 SID
    >> 
    >>     - A FIB entry that represents a local interface, not locally
    >>       instantiated as an SRv6 SID
    >> 
    >>     - A FIB entry that represents a non-local route
    >> 
    >>     - No Match
    >> 
    >> Section 4:
    >>> Each FIB entry indicates the behavior associated with a SID instance
    >>> and its parameters.
    >> 
    >> Thank you,
    >> Pablo. 
    >> 
    >> -----Original Message-----
    >> From: Christian Hopps <chopps@chopps.org>
    >> Date: Tuesday, 10 March 2020 at 22:01
    >> To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
    >> Cc: Christian Hopps <chopps@chopps.org>, "spring@ietf.org" <spring@ietf.org>
    >> Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12
    >> 
    >> 
    >> 
    >>> On Mar 10, 2020, at 2:13 PM, Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org> wrote:
    >>> 
    >>> Hi Chris,
    >>> 
    >>> Thanks for going through the document.
    >>> The behaviors 4.13 (End.B6.Encaps), 4.14 (End.B6.Encaps.Red) and 4.15 (End.BM) correspond to Binding SIDs [1].
    >>> 
    >>> As a result of 4.13 for example, the packet is encapsulated with a new IPv6 header and an SRH that contains the SR policy associated to the BSID.
    >>> Once the new IPv6 header is pushed into the packet, the NET-PGM pseudocode passes this packet to the IPv6 module of the router for transmission.
    >>> 
    >>> Normally the Upper-Layer Header should not be processed on a packet with a BSID, since you have just pushed an SR policy into the packet.
    >>> That said, when the ultimate destination is BSID, then the Upper Layer Header processing is the same to End (4.1).
    >>> 
    >>> Hope it clarifies.
    >> 
    >>   I'm still not clear on things I guess, but your answer leads me to a more basic question:
    >> 
    >>   Section 4.1 described the basic "FIB entry" "End" which says:
    >> 
    >>     "When N receives a packet whose IPv6 DA is S and S is a local End SID, N does..."
    >> 
    >>   So it's talking about a FIB entry for a "local End SID".
    >> 
    >>   Section 4.1.1 says:
    >> 
    >>     "When processing the Upper-layer Header of a packet matching a FIB
    >>      entry locally instantiated as an SRv6 End SID"
    >> 
    >>   It's talking about a "FIB entry locally instantiated as an SRv6 END SID"
    >> 
    >>   I'm not understanding how these 2 things are different. 4.1s calling a FIB Entry a "local End SID" 4.1.1 is calling something (different?) a "FIB Entry locally instantiated as an SRv6 END SID".
    >> 
    >>   The terms seem too similar for me to make a distinction, where I feel the document expects me to make one.
    >> 
    >>   Thanks,
    >>   Chris.
    >> 
    >> 
    >>> 
    >>> Thanks,
    >>> Pablo.
    >>> 
    >>> [1]. https://tools.ietf.org/html/rfc8402#section-5
    >>> 
    >>> 
    >>> -----Original Message-----
    >>> From: spring <spring-bounces@ietf.org> on behalf of Christian Hopps <chopps@chopps.org>
    >>> Date: Saturday, 7 March 2020 at 12:50
    >>> To: "spring@ietf.org" <spring@ietf.org>
    >>> Cc: Christian Hopps <chopps@chopps.org>
    >>> Subject: [spring] Question on draft-ietf-spring-srv6-network-programming-12
    >>> 
    >>>  In sections 4.13, (implicitly in 4.14) and 4.15 a set of steps is indicated. As far as I can tell the processing of the IPv6 header chain in all cases is terminated. e.g.,
    >>> 
    >>>  "
    >>>     When N receives a packet whose IPv6 DA is S and S is a local End.BM
    >>>     SID, does:
    >>> 
    >>>    S01. When an SRH is processed {
    >>>    S02.   If (Segments Left == 0) {
    >>>  ....
    >>>                 Interrupt packet processing and discard the packet.
    >>>    S04.   }
    >>>    S05.   If (IPv6 Hop Limit <= 1) {
    >>>  ....
    >>>                 Interrupt packet processing and discard the packet.
    >>>    S07.   }
    >>>    S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
    >>>  ....
    >>>                 Interrupt packet processing and discard the packet.
    >>>    S11.   }
    >>>  ....
    >>>    S15.   Submit the packet to the MPLS engine for transmission to the
    >>>              topmost label.
    >>>    S16. }
    >>>  "
    >>> 
    >>>  The text then says:
    >>> 
    >>>     When processing the Upper-layer header of a packet matching a FIB
    >>>     entry locally instantiated as an SRv6 End.BM SID, process the packet
    >>>     as per Section 4.1.1.
    >>> 
    >>>  Why would I ever be processing the upper-layer header at this point?
    >>> 
    >>>  Thanks,
    >>>  Chris.
    >>>  _______________________________________________
    >>>  spring mailing list
    >>>  spring@ietf.org
    >>>  https://www.ietf.org/mailman/listinfo/spring
    >>> 
    >>> 
    >>> _______________________________________________
    >>> spring mailing list
    >>> spring@ietf.org
    >>> https://www.ietf.org/mailman/listinfo/spring
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> spring mailing list
    >> spring@ietf.org
    >> https://www.ietf.org/mailman/listinfo/spring
    > 
    > 
    > 
    > 
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.ietf.org/mailman/listinfo/spring
    >