Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Sun, 01 March 2020 07:41 UTC

Return-Path: <xiejingrong@huawei.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 7BFAF3A0991; Sat, 29 Feb 2020 23:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 N1TIoHsPdcEV; Sat, 29 Feb 2020 23:41:21 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BDF703A0994; Sat, 29 Feb 2020 23:41:20 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B0D9DD2ABA4D6191262A; Sun, 1 Mar 2020 07:41:17 +0000 (GMT)
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 1 Mar 2020 07:41:17 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 1 Mar 2020 15:41:14 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Sun, 1 Mar 2020 15:41:14 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AQHV7vBP1vfKkAk0jUC5j6zg6cFRZ6gx7GUAgAAK64CAABAIgIAAGc0AgAAOhoCAAFqWAIAAzjoAgAACYzA=
Date: Sun, 01 Mar 2020 07:41:14 +0000
Message-ID: <48e149707a694ee19b6041579d59e178@huawei.com>
References: <965ff6bbf1cb4c2f8d48b7b535a0cf5b@huawei.com> <CAJE_bqcTNWt==mtYKeNVXOBAzBNLG=+_mXQQ9xMHYOCDRqCb_Q@mail.gmail.com> <CAOj+MMEzbyzy98iFyfe6Z=dQiWHo=triX6bHKx9fNEUCaSuy3Q@mail.gmail.com> <085238CD-14F6-43AE-8D58-49A20DDCBB24@juniper.net> <CAOj+MMGzjP4C4CXi+6i+o_TMO5Un8HdGF+MMGLVa-KPUH+pXZw@mail.gmail.com> <BB541BBF-5E31-4B9E-BACF-4C75BE640A64@juniper.net> <CAOj+MMGNC=4csgAeL5DfV1hhTAgzTfwmaS_GE6HQqEvziENbtA@mail.gmail.com> <40396035-12B4-4A58-9842-78547EBFF4FC@juniper.net> <995238762d214578ba3da4a79dbca6c9@nokia-sbell.com> <8cb1e9d623764930a767a125b74a9968@huawei.com>
In-Reply-To: <8cb1e9d623764930a767a125b74a9968@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.214.154]
Content-Type: multipart/alternative; boundary="_000_48e149707a694ee19b6041579d59e178huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/l_HHheWw6BltoUFkougP0Us1xgE>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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, 01 Mar 2020 07:41:24 -0000

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW]----[rtA----rtB----rtC]----subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending to the subscriber for 3 benefits:

(1)     Save bandwidth needed to carrying this SRH through SP network

(2)     Not boring subscribers to deal with SRH.

(3)     Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion ---- for IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:jgs=40juniper.net@dmarc.ietf.org>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all endpoints (segments) in SRH associated the outer IPv6 header are intermediate nodes to be visited, including endpoint identified by SL=0. so it is meaningless to entangle in the outer packet SRH which segment belongs to the ultimate destination address of the outer IPv6 packet; I think the roles of all segments in the SRH are the same which are used to perform part of total network programmable functions within SRv6 domain, their positions are the same, so there is nothing wrong for PSP in some ways, It is not necessary for segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what our point of disagreement is :-) and I think we can leave it there until there is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end of src route) - honestly I have not seen such definition in any IETF document except in the proposed errata stating that SL==0 to consider destination an final destination. /* So if RH is removed before we would never reach final destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each destination node where DA from packet's header matches the address of one of its local interfaces. It is also the ultimate/final destination for specific segment as to reach it packet could have traversed many non SR capable nodes. As Dirk mentioned SR path can be represented by set of autonomous segments each doing complete decasulation and new encapsulation of the packet based on the SRH content. If so there is no violation of anything. /* And in this mode at least SR nodes could be PLRs for TI-LFA without the need for yet one more encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> wrote:
I see. So you are simply demonstrating that even the tightened language you quoted is subject to the same difference of interpretation that’s at the root of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a source-routed packet cannot be said to have reached its ultimate destination until it has reached the target of the source route, the point at which the source route has been fully consumed. I think (?) you'll agree that isn't the interpretation you've chosen, you’ve chosen to interpret “ultimate destination” as meaning “the destination depicted in the outer IPv6 header," regardless of where the packet is along the source route. Right? So, status quo ante. (I think I could defend my reading as being objectively correct based on nothing more than the words as written, but that’s beside the point — once we get to the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural language can often be interpreted differently by different readers (especially those motivated to reach different interpretations) and leave it at that, resolving such differences when they arise through IETF process; or work to craft ever more precise language, accepting the consequence that we have to do extra work and our specs become more unwieldy as a result. In this particular case, I guess an excruciatingly precise definition of “ultimate destination” may be the key to resolving ambiguity.

—John

On Feb 29, 2020, at 1:25 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 operation. If this would be deprecated, moved to historic or made illegal - games over. But if this is still legal then ultimate destination for a packet is what it listed in outer IPv6 header DA. That's pretty basic. Now what the destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of course it can. You are looking flat .. If you look at different layers the same node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> wrote:
Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of messages that have gone before, not to mention the plain language of draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is enough to prove this: by definition a node can’t be both the penultimate, and the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would be a different story, but the whole point of PSP is that X removes the RH and then sends the encapsulated packet on to Y which performs the decapsulation. (This point was made in one of the other threads recently, but I’ve lost track of by whom and which thread.) As far as I can tell, this non-controversial behavior is described in 4.16.3 of the draft and referred to as “USD”.

—John

On Feb 29, 2020, at 6:06 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its source node and extension headers cannot be removed from a packet until it has arrived at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason being is that we are dealing here with an *encapsulated* packet which has as its ultimate destination SR node X. That SR node X is to perform or not PSP. So it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 really mandates you to look at segments_left before processing the packet or it is equally legal to look at that value after local processing occurs. Definition says:



      Segments Left       8-bit unsigned integer.  Number of route

                          segments remaining, i.e., number of explicitly

                          listed intermediate nodes still to be visited

                          before reaching the final destination.

which to me really means that as long as you recognize given routing header type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:


 S14.1.   If (Segments Left Before Local Decrement == 1) {

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

Many thx,
R.

On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>> wrote:
At Fri, 28 Feb 2020 07:54:28 +0000,
"Xiejingrong (Jingrong)" <xiejingrong@huawei.com<mailto:xiejingrong@huawei..com>> wrote:

> The design of PSP for the benefits of deployment is based on the understanding
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> modified in the future, the PSP may also need to change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to
discuss it at this level due to the poor editorial work then (I was
also responsible for that as one of those reviewing the bis draft),
but anyone who involved the discussion should know the intent of this
text intended to say (borrowing from Ron's text) "Extension headers
cannot be added to a packet after it has left the its source node and
extension headers cannot be removed from a packet until it has arrived
at its ultimate destination".  It might look "an attempt of blocking
an innovation by a small group of vocal fundamentalists", but if you
see the responses without a bias, you'd notice that even some of those
who seem neutral about the underlying SRv6 matter interpret the text
that way.

I'd also note that simply because PSP violates RFC8200 doesn't
immediately mean it (PSP) "needs to change".  It can update RFC8200 with
explaining why it's necessary and justified.  That's what I
requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's justified.

And, since PSP at least wouldn't break PMTUD, I guess the update
proposal will have much more chance to be accepted than a proposal
including EH insertion.  On the other hand, pretending there's no
violation will certainly trigger many appeals and objections at the
IETF last call (I'll certainly object to it).  In the end, it can
easily take much longer, or even fail, than formally claiming an
update to RFC8200.

--
JINMEI, Tatuya

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$>
--------------------------------------------------------------------