Subject: Questions on draft-yang-rtgwg-ipv6-associated-channel

From: Greg Mirsky <[email-masked]>
Date: Thu, 4 Mar 2021 20:07:05 -0800

Dear Authors,
thank you for sharing your ideas in this new draft. I have several
questions after reading the draft. Because of our tight schedule next
week I may not be able to join in the 6man WG session for your
presentation. I much appreciate your kind consideration of my questions:

   - in Section 3.3.4 you describe the case of including the ACH TLV as
   IPv6 packet's payload. Do you envision that in that case ACH TLV is carried
   over UDP transport or as raw IP? If you planned using UDP, which
   destination port number the ACH will use - assigned by IANA from the System
   Ports or User Ports ranges or from the Dynamic/Private Ports range?
   - If you plan to carry IPv6 ACH over UDP, my next question is related to
   Section 4.2. Over years, several broadly used OAM protocols that use UDP
   transport have been defined at IETF. For example, BFD, S-BFD, TWAMP, and,
   most recently, STAMP. What are the benefits of carrying their respective
   control messages over the IPv6 ACH rather than over UDP, using assigned
   destination port numbers?
   - I would note that RFC 6378 is applicable to linear e2e protection
   switchover coordination. But that is not applicable in the case of shared
   mesh protection. For that case, I can point to RFC 7412
   <https://tools.ietf.org/html/rfc7412>.

Best regards,
Greg

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Fri, 5 Mar 2021 13:00:55 +0000

Hi Greg,
Thank you for your questions. They are all good questions, continuously been kept asking us when we initially had the ACH idea.
My reply is followed, please see inline.

Regards,
Fan

发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2021年3月5日 12:07
收件人: [email-masked]; 6man WG <[email-masked]>
抄送: Greg Mirsky <[email-masked]>
主题: Questions on draft-yang-rtgwg-ipv6-associated-channel

Dear Authors,
thank you for sharing your ideas in this new draft. I have several questions after reading the draft. Because of our tight schedule next week I may not be able to join in the 6man WG session for your presentation. I much appreciate your kind consideration of my questions:

  *   in Section 3.3.4 you describe the case of including the ACH TLV as IPv6 packet's payload. Do you envision that in that case ACH TLV is carried over UDP transport or as raw IP? If you planned using UDP, which destination port number the ACH will use - assigned by IANA from the System Ports or User Ports ranges or from the Dynamic/Private Ports range?
<yf> Encapsulating ACH TLV in payload actually is a very different from encapsulating it in IPv6 extension headers. If it does, we consider to carry ACH TLV as raw IP. The idea of this draft is to build an associated channel for IP layer, by making use of capabilities of IPv6 itself, not depending on upper layers. If ACH TLV is encapsulated as payload, a new codepoint of IP Protocol Numbers should be assigned.

  *   If you plan to carry IPv6 ACH over UDP, my next question is related to Section 4.2. Over years, several broadly used OAM protocols that use UDP transport have been defined at IETF. For example, BFD, S-BFD, TWAMP, and, most recently, STAMP. What are the benefits of carrying their respective control messages over the IPv6 ACH rather than over UDP, using assigned destination port numbers?
<yf> Again, ACH TLV will be encapsulated in IPv6 extension headers or raw IP in payload, there is no transport layer. Supporting OAM based on transport layer results in two problems. One, the scalability of sessions. Second, OAM session can only be E2E, the intermediate node in between cannot be involved. For example, it is not possible to report the signal degradation happened on intermediate node.
Actually here you raise a very good point. By changing a bit of your original question, my question is what are the benefits of carrying different respective control messages over different OAM protocols that are all based on UDP, using different destination port numbers? By using ACH TLV, maybe it is a good start to have a unified format of different OAM control messages.

  *   I would note that RFC 6378 is applicable to linear e2e protection switchover coordination. But that is not applicable in the case of shared mesh protection. For that case, I can point to RFC 7412<https://tools.ietf.org/html/rfc7412>.
<yf> Thank you for the pointer. I heard linear and ring protection, but have no idea there was SMP. Oops!
After a quick check, it provides a very interesting way to design the protection mechanism in a mesh network. I don’t know whether the reason you point to this document is because IP is a mesh network, probably it is better to use the mesh protection protocol. Actually it is just opposite to what I thought. There have been many LFA mechanisms used in IP, and LFA is naturally oriented to mesh network. On the other hand, linear protection provides E2E protection to a specific path. By adopting it to IP, an IP service can be protected as a tunnelized service.
Of course, the signaling of SMP can also be carried in ACH if we decide to use it in IP. I need more time to look into it.

No worry about missing the presentation in 6man, you can also catch it in rtgwg session II on Friday.

Cheers,
Fan

Best regards,
Greg