Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

"Chengli (Cheng Li)" <c.l@huawei.com> Fri, 22 October 2021 03:12 UTC

Return-Path: <c.l@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 BC15F3A0AFA; Thu, 21 Oct 2021 20:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bfqppvO7EaW5; Thu, 21 Oct 2021 20:12:06 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C195B3A0AB0; Thu, 21 Oct 2021 20:12:05 -0700 (PDT)
Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hb8Rq5Z3Kz67sMs; Fri, 22 Oct 2021 11:08:07 +0800 (CST)
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 05:12:01 +0200
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500003.china.huawei.com (7.185.36.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 11:12:00 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2308.015; Fri, 22 Oct 2021 11:12:00 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
Thread-Index: AQHXxKTt3WUDAyZqfEC85Z4zSXmOTqvbzoOAgAEvI4CAAJEZgIAAzL0g
Date: Fri, 22 Oct 2021 03:12:00 +0000
Message-ID: <838f3074802b4b67b33b7153d2f7089e@huawei.com>
References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> <CA+RyBmUo6+_EgN=EbeuWPrP-NBLZ15ag_2P-pB4k43gc7gnQmA@mail.gmail.com> <BN6PR11MB408139C73921509416BACE4EC8BF9@BN6PR11MB4081.namprd11.prod.outlook.com> <CABNhwV2ZDsCKfwMvniDUKGRmFk2tyeuG7kOYu1ek+HKUdpDSTQ@mail.gmail.com>
In-Reply-To: <CABNhwV2ZDsCKfwMvniDUKGRmFk2tyeuG7kOYu1ek+HKUdpDSTQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.81]
Content-Type: multipart/related; boundary="_004_838f3074802b4b67b33b7153d2f7089ehuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oZFikqpU1ApZNqxG_upnKzF4MjE>
Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
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: Fri, 22 Oct 2021 03:12:17 -0000

Hi Gyan,

Sorry I don’t understand the case you mentioned. Could you please provide an easy example? How a SID will be shifting in a GSID container?

Respect,
Cheng


From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gyan Mishra
Sent: Friday, October 22, 2021 6:58 AM
To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>
Cc: spring@ietf.org; ipv6@ietf.org
Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression



Hi Darren

What Greg is asking is if the SID is a prefix SID End and not adjacency SID End.x, so now the common prefix is needed to ECMP steer the flow  to the prefix SID which uses the common prefix,  which may in this case be mutated due to shifting of SIDs in GSID container.


Kind Regards

Gyan
On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hi Greg,

Your question is not clear to me.
Can you try to restate it with the flavors and behaviors from the draft in question?

Darren

On 2021-10-20, 4:15 PM, "ipv6" <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> wrote:

Hi Brian,
I've got some questions about what you've said:
For that reason, the fact that the bottom 64 bits in the
"address" look funny or change is simply irrelevant. They are
invisible to routing (which is done based on the prefix)
and invisible to neighbor discovery (because it never happens).
As I understand it, what you describe is the case of a strict explicit path defined using one of the C-SID compression methods. But I am not sure that your conclusion also always applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the same prefix, how routing can be done based only on that prefix and not using a part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can guarantee that CIDR still works in that domain?

Regards,
Greg

On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
Hi,

After reading a lot of messages, I'm going to offer my considered
opinion as a direct response to Joel's OP.

Firstly, I don't believe that in the end this draft raises any
concerns that are *significantly* different than those raised
when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
of RFC 8754 explains that SIDs of any shape or size are only
meaningful within an SR domain. That applies to srh-compression
too.

Secondly, I was concerned about how these strange looking
"addresses" would potentially interfere with normal IPv6
addresses and their handling by normal IPv6 nodes. Well, I
now believe that they won't. The reason is that in the SR model
these "addresses" are *never used for final delivery of IPv6
packets to a host.* All SRv6 participants are routers. The
last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
is *not* the last hop on a LAN, mediated by neighbor discovery
for 2001:db8:a:1900::. It's just a hop from one router to another,
using the entry for 2001:db8:a:1900::/64 in the FIB of the last
router that actually forwards the packet. 2001:db8:a:1900:: is
not assigned to a physical interface so RFC 4861 is never invoked.

Another way to say it is RFC 7608 is the relevant architectural
standard. CIDR rules, even within an SR domain.

For that reason, the fact that the bottom 64 bits in the
"address" look funny or change is simply irrelevant. They are
invisible to routing (which is done based on the prefix)
and invisible to neighbor discovery (because it never happens).

I apologise if this is all obvious to everybody, but I needed
to spell it out for my own understanding.

Now back to Joel's questions:


On 13-Oct-21 20:37, Joel M. Halpern wrote:
> There is a typo in the below which if not understood as a typo would be

> quite confusing.   I wrote that I raised the issue with
> "with the Internet ADs and SPRING chairs".
> That should have read "with the Internet ADs and 6man chairs".
> The SPRING co-chairs are recused, and the charter requirement leads to
> the 6man chairs.  Which is who I talked to.
>
> Also, I am sending a courtesy copy to the routing ADs, which I should
> have done originally.
>
> Thank you and enjoy.
> Yours,
> Joel
>
> On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
>> The SPRING working group is in the midst of an adoption call on
>> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.
>>
>>
>> The SPRING charter has text that is explicit that modifications to data
>> planes and architectures standardized by other working groups may not be
>> modified in SPRING unless the chairs and ADs responsible for that data

>> plane and / or architecture agree.
>>
>> To complete the context, as my SPRING co-chairs are co-authors on the
>> document in question, they have recused themselves from decisional
>> activities regarding the document.  Therefore, this message is coming
>> just from my as the responsible SPRING co-chair managing this adoption

>> call.
>>
>> As you have seen, multiple questions have been raised about the
>> relationship of the document to the IPv6 defined data plane and
>> architecture (particularly RFC 4291 and 8200). In particular the
>> questions seem to revolve around what the document describes as the
>> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
>> standards.  (For those seeking more context without reading the full
>> document, a paraphrase and simplification of the NEXT-C_SID flavor is
>> provided as a postscript.)
>>
>> I raised the question of concurrence as required by the SPRING charter

>> with the Internet ADs and SPRING chairs.  They quite reasonably asked me
>> to write a note to 6man explaining the concerns as clearly as a can, so
>> that they can then determine how to proceed.
>>
>> The questions that prompted my inquiry are:
>>
>> 1) Does the placement of a list of sids in the IPv6 DA field change the
>> IPv6 architectural description of that field.

I think it should be noted explicitly somewhere that since the contents
of the DA field are *never* used for last-hop neighbor discovery,
the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
are irrelevant. Another citation is RFC 7608: for routing, all that
counts is the prefix, and it can be anything up to 128.

Perhaps this should have been in section 5 of RFC 8754, but I leave
that to the wordsmiths.

>> 2) Does the operation of shifting information around in the IPv6
>> destination address field represent a modification or extension of the

>> IPv6 data plane.

No. As my text above indicates, the SRv6 DA field is only ever used
by routing, where RFC 7608 rules. And of course it vanishes as soon
as the packet is decapsulated.

Regards
    Brian

>>
>> On a related note, the document in question also defines two other
>> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
>> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
>> flavor operation, so seems to be affected by the same question.
>>
>>  From my own reading, it appears that the REPLACE-C-SID flavor does not
>> raise issues requiring 6man leadership concurrence.
>>
>> Yours,
>> Joel M. Halpern for the SPRING working group
>>
>>
>> PS:
>> Clearly, understanding the question requires some understanding of what
>> the NEXT-C_SID flavor does.   This explanation is a simplification for
>> length and context.  Really, the best place to understand it is the
>> draft.  However, to give you enough information to let you decide

>> whether you care, I will try to provide a fair summary.  My apologies in
>> advance to the authors for necessary liberties for length.  Also,

>> discussion of the draft contents (as distinct from the interaction with
>> the IPv6 data plane and architecture) belongs on the SPRING list, and
>> should not clutter up 6man.
>>
>> SIDs are the identifiers used in segment routing.
>> In SRv6, as document in the current RFCs, these are 128 bits.   As
>> defined in the relevant RFCs, SIDs which identify endpoints to which
>> packets are directed are identified by endpoint SIDs.  These can have
>> behaviors (decapsulate and forward is one example).  They can have
>> flavors such as where the SRH is removed.
>>
>> The topic under discussion is means to compress these SIDs in the
>> packets on the wire.  The document under discussion provides three
>> flavors of compression.
>>
>> The fundamental mechanism of the draft is to use a single SRH entry as
a
>> container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is
>> first encountered the entire container is copied into the desination
>> address of the IPv6 packet.  The container has a common routing prefix
>> used for all the NEXT-C-SID SIDs.  It is followed by a sequence of
>> compressed SIDs of a configured length.  One could configure 16, 24, or
>> 32 bits.  Or whatever length.  The routing advertisements are arranged
>> so that the IPv6 packet is directed to the node represented by the first
>> compressed SID on the basis of longest prefix match matching the
>> combination of the common routing prefix and that compressed SID.
>>
>> When the packet arrives at that node, it looks up the configured
>> portion, the compressed SID, and determines the behavior and flavor.  In
>> the case of the NEXT-C-SID flavor, the resulting operation is to shift

>> the entire remaining contents of the IPv6 address (the bits past the
>> first compressed sid) so as to over-write the first compressed SID.  0
>> bits are shifted into the low order positions.  If the result is a
>> non-zero new first compressed SID, then the packets is forwarded and the
>> process repeats.  When all that is left are 0s, if there is an SRH, it
>> is consulted to find the next SRH entry, which is, per normal SRv6
>> processing, put into the IPv6 DA.
>> Note that in the common case where the SIDS needed all fit in to a
>> single container, the analysis also assumes the use of the reduced
>> encapsulation options which omits the SRH that is not needed as it would
>> have no entries.  This the packet contains a normal IPv6 header, with a
>> sequence of compressed SIDs (what one might or might not call a source

>> route) in the IPv6 destination address field.
>>
>> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented
>> the work, please, send clarifications or corrections.   Again, the best
>> source of information is the draft itself.  I was asked to provide extra
>> context in this email.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org<mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347