Hi Yao, Please see zzh2> below.
Juniper Business Use Only From: liu.ya...@zte.com.cn <liu.ya...@zte.com.cn> Sent: Friday, May 16, 2025 4:11 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> Cc: rtgwg@ietf.org Subject: Re: [rtgwg] Re: Request for more discussion/feedback on draft-zzhang-rtgwg-router-info [External Email. Be cautious of content] Hi Jeffrey, Thanks for the reply. Please see Yao> below. Yao Original From: Jeffrey(Zhaohui)Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> To: 刘尧00165286; Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>; Date: 2025年05月15日 22:57 Subject: RE: [rtgwg] Re: Request for more discussion/feedback on draft-zzhang-rtgwg-router-info Hi Yao, Thanks for your comments. Please see zzh> below. Juniper Business Use Only From: liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn> <liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> Sent: Wednesday, May 14, 2025 9:17 PM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org> Subject: [rtgwg] Re: Request for more discussion/feedback on draft-zzhang-rtgwg-router-info [External Email. Be cautious of content] Hi Jeffrey, I have a few comments/questions after reading the draft. 1. If the periodic message sending is not required, how would the Refresh Rate field be filled . Should a specific value or a flag defined for this purpose？ Zzh> We can use 0. I assume that’s only for one-time-ok-to-lose notifications. I’ve updated the draft in my local copy. 1. About section 2.5 flow redirection, besides 5 tuples, there's possibility that other fields would be used to identify a traffic flow, is there any consideration on this, e.g.,introducing optional fields such as user defined fields in Flow Redirection TLV for better compatibility? Zzh> In general, we try to avoid sub-TLVs to allow maximum packing and to simplify the processing, especially since some of the notifications are to be handled at very low level, as mentioned in the draft: The following TLVs are defined to allow maximum packing. If additional information needs to be advertised, new TLVs may be defined without using sub-TLVs to allow efficient encoding of additional information, or with sub-TLVs to allow flexibility but at the cost of processing complexity. Yao> Understand，new information doesn't have to be defined in the format of sub-TLVs Zzh> What are other fields that may be frequently used? Yao> For the traffic redirection scenario, some solutions may use different fields as supplement or replacement for 5 tuples， which directly or indirectly affects the flow path selection. I don't know clearly the most frequently used fields, but the possible fields include IPv6 flow label, or user defined path ID that's embed in the packet header. The point is, some solutions may choose to use their own fields for traffic path selection, would this draft consider to cover this situation, e.g, by providing optional user-defined field in Flow Redirection TLV or just leave it for future consideration, who needs other fields besides 5 tuples for traffic redirection can define their own TLV if they want to. Zzh2> I would opt for defining new TLVs. We can make (part of) the TLV type registry FCFS, so that it is very easy to register new TLV types for extension. I’ve updated the local copy of the draft accordingly. 1. What's the value of Link ID field in the message header when BGP is used in the network. Zzh> The Link ID in the message header is the ID of the link on which the flooding happens. For example, you have five links 1~5 and on link 1 you flood info about links 2~5 then the Link ID in the message header is 1. Yao> So when BGP is used in the network, the Link ID field may be filled with be a local interface address that identifies the flooding link? Zzh2> BGP is not used for flooding. UDP is, and the messages are sent on the individual links in the case of local flooding. The ID of the sending link is included in the message header. One may say that it is not really that useful. I don’t have a strong argument either way, but it’s just a 4-octet field and not repeated. Zzh2> If BGP is used as the routing protocol as in draft-wang-idr-next-next-hop-nodes, then the UDP messages include Neighbor Path Information TLV where each neighbor is identified by a Neighbor ID, but the message header still includes the Link ID of the link on which the message is sent. Zzh2> Jeffrey Zzh> Thanks. Zzh> Jeffrey Regards, Yao
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
