Hi Jeffrey,
Thanks for the reply. Please see Yao> below.
Yao
Original
From: Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
To: 刘尧00165286;
Cc: rtgwg@ietf.org <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 <liu.ya...@zte.com.cn>
Sent: Wednesday, May 14, 2025 9:17 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: 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.
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.
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.
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?
Zzh> Thanks.
Zzh> Jeffrey
Regards,
Yao
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
