Thank you. That looks good.
Joel
On 2/16/2024 11:06 AM, Jeffrey (Zhaohui) Zhang wrote:
Hi Joel,
I posted the -05 revision. Besides the proposed text below, I also added an IANA request for the "BIER Helped Node" sub-TLV type for OSPFv3 - I had missed that.
https://author-tools.ietf.org/iddiff?url1=draft-ietf-bier-tether-04&url2=draft-ietf-bier-tether-05&difftype=--html
Thanks.
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: Joel Halpern <jmh@xxxxxxxxxxxxxxx>
Sent: Thursday, February 15, 2024 11:27 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>; gen-art@xxxxxxxx
Cc: bier@xxxxxxxx; draft-ietf-bier-tether.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [Bier] Genart last call review of draft-ietf-bier-tether-04
[External Email. Be cautious of content]
Thank you Jeffrey. On the major item, the proposed text addresses my concern.
On the minor issue, thank you. I had failed to put the pieces together in my head, and you are correct. Bier operation will take care of the problem and there is nothing to specify here. (In fact, that is the point. It just works.)
Yours,
Joel
On 2/15/2024 11:04 PM, Jeffrey (Zhaohui) Zhang wrote:
Hi Joel,
Thanks for your review and comments.
Please see zzh> below.
Juniper Business Use Only
-----Original Message-----
From: BIER <bier-bounces@xxxxxxxx> On Behalf Of Joel Halpern via
Datatracker
Sent: Thursday, February 15, 2024 6:10 PM
To: gen-art@xxxxxxxx
Cc: bier@xxxxxxxx; draft-ietf-bier-tether.all@xxxxxxxx;
last-call@xxxxxxxx
Subject: [Bier] Genart last call review of draft-ietf-bier-tether-04
[External Email. Be cautious of content]
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at
<https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!HnoMr9CvW2ImbH6LVeQkh-4CIMEuSojS_TOKsafTWXlzUP7cmGEeUOIn5afkDw9ceS4tFN9KrmjCnaQ$ >.
Document: draft-ietf-bier-tether-04
Reviewer: Joel Halpern
Review Date: 2024-02-15
IETF LC End Date: 2024-02-29
IESG Telechat date: Not scheduled for a telechat
Summary: This document is almost ready for publication as a proposed
standard
Major issues:
Section 3.1 on IGP Signaling states "The helper node (BFRx) MUST advertise
one or more BIER Helped Node sub-sub-TLVs". However, I only find a vague
outline of this sub-sub TLV. The code point for it is requested in the
IANA considerations section, but the description is a single sentence
easily misread and lacking the conventional diagrams and precision that is
used to define routing TLVs (and sub or sub-sub TLVs.)
zzh> Point taken. How about the following?
Suppose that the BIER domain uses BIER signaling extensions to ISIS
[RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise
one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in
the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in
the case of OSPF, one for each helped node:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address of the Helped Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is TBD1 (in the case of ISIS) or TBD2 (in the case of OSPF).
The Value field starts with a one-octet Priority field, followed by a
one-octet Reserved field, and then the Address of the Helped Node
(X). The Length is 6 for IPv4 and 18 for IPv6 respectively.
Minor issues:
In the paragraph about multiple helpers helping a single non-supporting
router, I think I missed how one case works properly. (Section 2,
additional considerations, paragraph 6). The text says that the sending
BFR (BFR1 can choose to use multiple helpers if they are available.
Assuming that BFR1 chooses to use BFR2 and BFR 3 to reach BFRs 4 .. BFR N,
the text is clear that this results in BFR2 and BFR 3 both sending copies
of the packet to Router X. That is fine. It is load, but it is a
tradeoff. However, it appears that both BFR2 and BFR 3 would send packets
to BFR4, and to all the other BFR children of X. This results in duplicate
packets in the rest of the tree. Is there some assumption I missed that
prevents this?
Zzh> The BIER forwarding algorithm ensures that the two copies of the same packet that a BFR sends out never have overlapping bits in the BitString. Therefore, no duplication will happen.
Zzh> Thanks!
Zzh> Jeffrey
Nits/editorial comments:
_______________________________________________
BIER mailing list
BIER@xxxxxxxx
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
__;!!NEt6yMaO-gk!HnoMr9CvW2ImbH6LVeQkh-4CIMEuSojS_TOKsafTWXlzUP7cmGEeU
OIn5afkDw9ceS4tFN9KMmQkevA$
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
