Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt
Gyan Mishra <hayabusagsm@gmail.com> Sun, 15 December 2019 07:06 UTC
Return-Path: <hayabusagsm@gmail.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 B2CAF120019 for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 23:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tUFJFbRDPD0z for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 23:06:45 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC4F120005 for <spring@ietf.org>; Sat, 14 Dec 2019 23:06:45 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id p8so2877940iln.12 for <spring@ietf.org>; Sat, 14 Dec 2019 23:06:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RLX+XUWi2asMXB+yAOVBH0z6ywZFc36ZOA3taHD94js=; b=TnoN/Rz3+Fmr5ZjuQbLxqpWbyJNM8/qmpgIEAI53/EANujmNf23UlW6wVND5GjQqxM 4TKcQ9Un20dPZB48doZJrMPzyh5NDpbUb7hEJie9mISJNm6LMaQr25MLdjnzAWQkj6eL 5nPp+06GBPqQV8VFzVdjT4MdhffB+FGHBIHeEQwwIPT797CoR7g4DAeiO6ixHjVSLIf/ a8A6c5t75YW5RSaXqL4zQv5M6F5lyCSr/O0/UcFKi2Xi8hwD87nSvkZvRqGIVKEfy8ml UazwgnJyIxXS9n16fSOVUrqCJHPTbWfU+xXiW39QWPYLNOYaDwQn6gp+3s6RnZ5auYWp EXiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RLX+XUWi2asMXB+yAOVBH0z6ywZFc36ZOA3taHD94js=; b=nvAJdwmH6Ee89u3QrzS/GnoH/Bv9y+DlfNFwUm3Zu4IHrZUuZVB/AdGM2v/BHjzKHG I2iABw+RS/3K8SeI2LsjjaRCZDt2MBpsGduxGAbVN9IPvBnm0mxjyvPb5dxq90UbzS+j h69B5hgK5zo3VZi/34d24GNfKYCCuvfLbmz0yPvJAZ69K7Qz7dtV8jFlA2z/kXCL2Hwt 1DOUJOmfX0/YBSQu9dxzT4xrE+tgMB8nZR3ERPMr8BgGc/H138P+Da7+a6Ap3fnmwmPi QmptidyFb7Un0Mq3GL3YR1NkjMknnbSkfFIH3eu+UgcRVN6SCV/L0bJWVF5tlyJ9dyMt M4SQ==
X-Gm-Message-State: APjAAAUzqs7M2Jx9me0QfnmFBTYgV7J6sLBq9AoZwLQyGCpkf/8VvbgH ZTOQq4wPPBffIEqKyEnFx1WJbtO7K0JIM+uny8w=
X-Google-Smtp-Source: APXvYqyfxHMDV0NgdNeiBUVB+l3hRtn7cSxj6a9zThrLrwjhIg526CcMAB7rcvc5wmm7d4vmqKFyOKOh8G+Kv1mE9Gc=
X-Received: by 2002:a92:350d:: with SMTP id c13mr7616794ila.205.1576393604229; Sat, 14 Dec 2019 23:06:44 -0800 (PST)
MIME-Version: 1.0
References: <8532651c71c94715abfa96990aec3854@nokia-sbell.com>
In-Reply-To: <8532651c71c94715abfa96990aec3854@nokia-sbell.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 15 Dec 2019 02:06:33 -0500
Message-ID: <CABNhwV1FpyLFcZicFBxjE74WGUhAzkwFgzrn7_jLxm5OTO0XgQ@mail.gmail.com>
To: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>
Cc: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce7d3f0599b8bcf8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/qiAeE_xuJA7CObaybi83XqecXao>
Subject: Re: [spring] USD/USP question in 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: Sun, 15 Dec 2019 07:06:48 -0000
Hi Wang I have a question regarding the PSP, USP and USD sections I pasted below. I just sent an email to Spring WG related to PSP and technically why that is necessary as that is a legacy concept that has parity to MPLS but is not used today due to QOS issues. Please see that email related to that topic. In the PSP section can If we have to keep PSP can we add verbiage that states that PSP removal of the SRH header occurs on the Penultimate egress P node. In the USP section can we also add that all remaining SRH present in the packet are popped on the egress PE ultimate node. In looking at these 3 SID functions the PSP and USP pop the EH and the USP removes the 6in6 encapsulation so that the other end.x dt4 dt6 etc can pop the services L3vpn headers. Why can’t the USD 6in6 encapsulation removal be done on with the USP SID? Why does the USP and USD SID have to be separate? 4.16.1 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-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 (updated SL == 0) { S14.2. Pop the SRH S14.3. } 4.16.2 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.2>. USP: Ultimate Segment Pop of the SRH The SRH processing of the End, End.X and End.T behaviors are modified: the instructions S02-S04 are substituted by the following ones: S02. If (Segments Left == 0) { S03. Pop the SRH S04. } 4.16.3 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.3>. USD: Ultimate Segment Decapsulation The SRH processing of the End, End.X and End.T behaviors are modified: the instructions S02-S04 are substituted by the following ones: S02. If (Segments Left == 0) { S03. Skip the SRH processing and proceed to the next header S04. } Further on, the Upper-layer header processing of the End, End.X and End.T behaviors are modified as follows: Kind regards, Gyan On Sat, Dec 14, 2019 at 9:08 PM Wang, Weibin (NSB - CN/Shanghai) < weibin.wang@nokia-sbell.com> wrote: > Hi Pablo: > > > > After the 2 context assumption in previous version of this draft, “we > assume that there is no other extension header than the SRH.” and “We > assume > > that the SRH may be present multiple times inside each packet”, are > removed in this last draft, I feel a bit confusion on USD SID, as well as > combination of USD & USP. > > > > First, within the content of this last draft, the word “Further on” marked > red in the following pseudocode in section “4.16.3” is hard to understand > if the packet being processed has other EH embed between SRH and > Upper-layer header, such as AH or other EH, then the processing control of > this packet will be passed to normal IPv6 module from current SRH > processing module in SR-Node, so my question is : Can its control after > completing AH processing (for example) be back to SRH module (or call it > pseudocode module) to proceed the next header like “upper-lay header type > ==41 or 4”. > > Or, if not, Did you created a new EH processing protocol stack instance in > parallel to normal IPv6 module within the scope of SRH processing in > SR-node. > > > > 4.16.3. USD: Ultimate Segment Decapsulation > > > > S02. If (Segments Left == 0) { > > S03. Skip the SRH processing and proceed to the next header > > S04. } > > > > Further on, the Upper-layer header processing of the End, End.X and > > End.T behaviors are modified as follows: > > > > End: > > S01. If (Upper-layer Header type == 41 || 4) { > > S02. Remove the outer IPv6 Header with all its extension headers > > S03. Submit the packet to the egress IP FIB lookup and > > transmission to the new destination > > S04. } Else { > > S05. Send an ICMP Parameter Problem message to the Source Address > > Code 4 (SR Upper-layer Header Error), > > Pointer set to the offset of the upper-layer header. > > Interrupt packet processing and discard the packet. > > > > S06. } > > > > From my understanding, the all processing action about specific SID must > be completed successively. That is to say, upon USD, the upper-layer header > (type 41 or 4) must be followed the SRH header being processed currently, > or second SRH following the same rule (of course, the draft not considering > 2 or more successive SRHs). > > > > Second, the mixed SIDs function with combination of USD and USP (even > PSP&USD&USP), I think, it is easy to understand when the two assumption > above exist, but now I think it isn’t clear if you only provide the > following sentence in this draft, i.e. “if … else…” statement: > > “An implementation that supports the USD flavor in conjunction with > > the USP flavor MAY optimize the packet processing by first looking > > whether the conditions for the USD flavor are met, in which case it > > can proceed with USD processing else do USP processing.” > > This confusion is also described in my another mail. Of course, if the > first question is addressed then this confusion does not exist. > > > > By the way, is it really no different in text description before and after > the two context assumption above removed? > > > > > > *Cheers !* > > > > *WANG Weibin* > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/networking-technologies-consultant
- [spring] USD/USP question in draft-ietf-spring-sr… Wang, Weibin (NSB - CN/Shanghai)
- Re: [spring] USD/USP question in draft-ietf-sprin… Gyan Mishra
- Re: [spring] USD/USP question in draft-ietf-sprin… Gyan Mishra
- Re: [spring] USD/USP question in draft-ietf-sprin… Wang, Weibin (NSB - CN/Shanghai)
- Re: [spring] USD/USP question in draft-ietf-sprin… Wang, Weibin (NSB - CN/Shanghai)
- Re: [spring] USD/USP question in draft-ietf-sprin… Wang, Weibin (NSB - CN/Shanghai)
- Re: [spring] USD/USP question in draft-ietf-sprin… Pablo Camarillo (pcamaril)