[spring] 回复: A review of draft-ietf-spring-sid-as-source-address

[Feng Yang <[e-mail]>]

Hi Adrain,

 

I think this update has addressed all of your careful review comments. 😊

https://datatracker.ietf.org/doc/html/draft-ietf-spring-sid-as-source-address-01

 

 

BR,

Feng

 

发件人: Feng Yang <[e-mail]> 
发送时间: 2026年9月28日 9:56
收件人: '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
抄送: '[e-mail]' <[e-mail]>; 'Gyan Mishra' <[e-mail]>
主题: 回复: A review of draft-ietf-spring-sid-as-source-address

 

Hi Adrain, 

 

Thanks for your careful review. All of the comments are helpful, and we will come back with updates in next revision.

 

BR,

Feng

 

发件人: Adrian Farrel < <mailto:[e-mail]> [e-mail]> 
发送时间: 2026年9月27日 3:20
收件人:  <mailto:[e-mail]> [e-mail]
抄送:  <mailto:[e-mail]> [e-mail]
主题: A review of draft-ietf-spring-sid-as-source-address

 

Hi SPRING,

 

Congratulations to the authors on a new WG draft.

 

I watched the discussions during adoption triggered by Gyan's review and comments. It seems like some sort of agreement was reached, and I look forward to a new revision to address that.

 

At the same time, I have done my own review of the draft. I know it is annoying to get a review when there are agreed updates that haven't been made yet, but I figure that since there is a new revision being made, some work on nits may be easily incorporated at the same time.

 

Cheers,

Adrian

 

===

 

Abstract

 

I think we don't need the marketing statements in the Abstract. It is

enough to say:

 

OLD

   SRv6 is being rapidly deployed and is currently primarily used in

   trusted-domain backbone networks.  Both the carrier market and the

   enterprise market are adopting SRv6 for end-to-end service delivery.

NEW

   SRv6 is deployed in trusted-domain backbone networks for end-to-end

   service delivery in carrier and enterprise networks.

END

 

---

 

Abstract

 

I suggest:

 

OLD

   However, if a firewall exists along an SRv6 path, not only legitimate

   SRv6 traffic but also ICMP packets generated on SRv6 transit node

   will be dropped.

NEW

   However, a stateful firewall on an SRv6 path may drop both legitimate

   SRv6 traffic and ICMP packets generated on SRv6 transit nodes because

   the bidirectional traffic flows are asymmetrical.

END

 

---

 

Absract

 

s/proposal/document/

s/SID/a SID/

 

---

 

Introduction

 

Same changes as in the Abstract.

 

---

 

1.

 

OLD

   The reason has been elaborated in Section 8.1 of

   [I-D.draft-ietf-spring-srv6-security].  SRv6 implementations use the

   ingress PE's loopback IPv6 address as the outer IPv6 source address

NEW

   As described in Section 8.1 of [I-D.draft-ietf-spring-srv6-security],

   SRv6 implementations use the ingress PE's loopback IPv6 address as

   the source address in the outer IPv6 packet header.

END

 

---

 

1.2

 

Add "SRS" to the list

 

---

 

2.

 

   Only unicast traffic is eligible for using SID as source address.

 

Are you saying that this approach cannot be used for multicast? If so,

you need to say why.

 

Or maybe you are saying that this document is only interested in unicast

and that multicast is out of scope for this document. If so, just make

that clear.

 

---

 

2.

 

s/Several/Two/

s/SHOULD/should/

 

---

 

2.1.1

 

   The user traffic SHOULD use the SRv6 service SID as the source

   address of the outer IPv6 header.

 

Why is this "SHOULD"?

 

If you mean "to conform to this document an implementation SHOULD" then

I would have thought this is a MUST because the document is all about

getting through the firewall.

 

If you are giving advice that implementations would be well advised to

follow, then use "should".

 

---

 

2.1.1

 

   All those End.DX* and End.DT* SIDs

   except End.DT2M SHOULD be used for source address.

 

s/SHOULD/can/

 

---

 

2.2

 

   For SRv6 ping, the ICMP Echo Request MAY use an End SID as the outer

   IPv6 source address to verify the reachability of the return path.

 

Some confusion over the use of "MAY" I think.

It's true that the Echo Request MAY use an End SID.

However, if the intention is to verify the reachability of the return

path when there is a stateful firewall on the path, isn't this "MUST"?

 

---

 

3.1.1

 

s/taffics/traffic/

 

---

 

3.1.2

 

OLD

   The proposed solution is to unify the semantic of the source and

NEW

   The solution described in this document is to unify the semantic of

   the source and

END

 

---

 

4.

 

s/lists[RFC9800]/lists [RFC9800]/

 

---

 

Adding an Operational Considerations section per draf-ietf-opsawg-

rfc5706bis would be great. It doesn't need to be done before adoption,

but hopefully it can be added later down the line.