IETF Logo Mail Archive

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Chongfeng Xie <xiechf@chinatelecom.cn> Sat, 08 October 2022 06:02 UTC

Return-Path: <xiechf@chinatelecom.cn>
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 5FC5CC1522C5; Fri, 7 Oct 2022 23:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpt14pGZz95A; Fri, 7 Oct 2022 23:02:22 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id A8BF7C14F722; Fri, 7 Oct 2022 23:02:16 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.188:56304.1345359453
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.78 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 9D8222800BC; Sat, 8 Oct 2022 14:02:13 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([219.142.69.78]) by app0023 with ESMTP id ded025e7e3d7487bb7f8964071e97032 for suresh.krishnan@gmail.com; Sat, 08 Oct 2022 14:02:15 CST
X-Transaction-ID: ded025e7e3d7487bb7f8964071e97032
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 219.142.69.78
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Sat, 08 Oct 2022 14:02:11 +0800
From: Chongfeng Xie <xiechf@chinatelecom.cn>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
Cc: "fredbaker.ietf" <fredbaker.ietf@gmail.com>, IPv6 List <ipv6@ietf.org>, spring <spring@ietf.org>
References: <202210011022164739921@chinatelecom.cn>, <529B3497-2A89-4522-85D8-D6CF21B963C5@gmail.com>, <fccd2c35-941f-628f-edc1-275afa89c35f@joelhalpern.com>, <29FD4C02-85C1-4C3B-8D79-734FD73C6DC4@gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.24.96[cn]
Mime-Version: 1.0
Message-ID: <202210081402112607252@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart631316368802_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/RmwboeUdFJxRW59JTJ5SmJ8_mDM>
Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 06:02:24 -0000

Hello,
1. In secction 3, you mentioned "While looking at the transit nodes it becomes apparent that these addresses are used purely for routing and not for packet delivery to end hosts. " My understanding is that "routing" and "packet delivery to end hosts" are not mutually exclusive , so I propose the sentence should be changed to "While looking at the transit nodes it becomes apparent that these addresses are used for routing prior to deliverying the packet to end host."

2. Section 6 asks IANA to allocate /16 address block for the purposes described in Section 5.  Is this just for security control at the border of the domain to avoid the leakage of SRv6 information?  

Best regards
Chongfeng



xiechf@chinatelecom.cn
 
From: Suresh Krishnan
Date: 2022-10-03 10:34
To: Joel Halpern
CC: Fred Baker; Chongfeng Xie; IPv6 List; spring
Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
Hi Joel,
  Thanks for clarifying. 

On Oct 1, 2022, at 12:20 AM, Joel Halpern <jmh@joelhalpern.com> wrote:

Hmmm.   I read "signal" in the draft as "indicate".  That is, for example, if there is an address range defined to be reserved for SIDs then that range appearing in the destination address is the "signal".  

Yes. This was exactly the intent. Fred/Chongfeng, please let me know if there are any text changes I can make to remove any potential ambiguity.

Regards
Suresh

v2.23.0 | Report a Bug | By Email