Ballot for draft-ietf-pim-pfm-forwarding-enhancements
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Ketan has discussed the conflict with RFC 8364 that I will not cover here. Section 2.1, T-bit field description: 181 > T-bit (1 bit): Indicates transitivity. If set to 0, a router that 182 > does not support the TLV or any contained Sub-TLV MUST NOT forward 183 > the message. If set to 1, the message MAY be forwarded even if 184 > unsupported TLVs or Sub-TLVs are present. RFC 8364 Section 3.1 defines T-bit semantics as a TLV-level forwarding decision, not a message-level one: > T-bit: Transitive. A router not supporting the given type MUST include > the TLV in the forwarded message if and only if the Transitive bit is set. Under RFC 8364, T=0 means an unsupporting router drops the TLV from the forwarded message while still forwarding the PFM message with its remaining TLVs. Under this draft, T=0 means the unsupporting router MUST NOT forward the entire PFM message. These are fundamentally different behaviors with different interoperability consequences: an RFC 8364-compliant router that has not implemented this draft will apply TLV-level drop semantics, not message-level suppression. A PFM message containing a GSI TLV with T=0 would therefore be handled inconsistently depending on whether the transit router supports this document, creating a split-behavior scenario. The T=1 case also conflicts: RFC 8364's T=1 places a MUST obligation on unsupporting routers to include the TLV in the forwarded message. This draft replaces that with MAY, which is a weaker requirement and inconsistent with existing transitive-bit semantics. Finally, the draft does not specify what T-bit value an originating FHR MUST or SHOULD set when generating a GSI TLV. Given that the two possible values produce dramatically different behavior in unsupporting routers, this omission is a protocol specification gap. To resolve: Either (a) align the T-bit semantics with RFC 8364's TLV-level behavior (drop the GSI TLV but forward the message, and MUST include if T=1), provide a rationale for the deviation, and update the "Updates:" header accordingly; or (b) specify what T-bit value an FHR MUST set and explain how the message-level suppression behavior interacts with RFC 8364-compliant routers that have not implemented this draft.
ection 2.1, Sub-TLV unknown-type handling: 203 > Sub-TLVs: Zero or more Sub-TLVs MAY be included. Each Sub-TLV 204 > consists of: 205 > 206 > Type (16 bits): The Sub-TLV Type. Values for this field are 207 > assigned by IANA. 208 > 209 > Length (16 bits): The length, in octets, of the Value field. The 210 > length may be 0 if no value is present. 211 > 212 > Value: The content of the Sub-TLV, whose format is determined by 213 > the Sub-TLV Type. The draft defines a Sub-TLV format but does not specify what a supporting router MUST do when it encounters a Sub-TLV type it does not recognize. Should it ignore the Sub-TLV and continue processing the GSI TLV? Drop the entire GSI TLV? Skip the Sub-TLV and forward the GSI TLV? RFC 8364 addresses this for outer TLVs via the T-bit, but no analogous mechanism is defined for the Sub-TLV layer. The draft should specify skip-and-continue semantics (or equivalent) for unrecognized Sub-TLV types. Section 1.2, Terminology: 63 > 1.2. Terminology 64 > 65 > RPF: Reverse Path Forwarding 66 > 67 > FHR: First-Hop Router 68 > 69 > PFM-SD: PIM Flooding Mechanism and Source-Discovery "Relaxed-RPF" is used as a key concept in the Section 3.4 heading ("PFM message handling with Relaxed-RPF enabled") and in the bullet list within that section, but it is not defined here in Section 1.2. It should be added with a brief definition that distinguishes it from standard RPF behavior. ---------------------------------------------------------------------- NIT ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1, GSI TLV format diagram, Group Address and Source Address rows: 154 > 0 1 2 3 155 > 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 156 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 > |T| Type = TBD1 | Length | 158 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 > | Group Address (Encoded-Group format) | 160 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 > | Source Address (Encoded-Unicast format) | 162 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Group Address and Source Address are depicted as single 32-bit rows, but the accompanying text states they are variable-length: 64 bits for IPv4 and 160 bits for IPv6. The diagram should use an ellipsis or multi-row notation to avoid implying these are fixed 32-bit fields, consistent with how RFC 7761 depicts Encoded-Group and Encoded-Unicast fields.
** Section 5. Also, a new registry "PIM Flooding Mechanism Group Source Info Message Types" registry needs to be created. Assignments for the new registry are to be made according to the policy "IETF Review" as defined in [RFC8126]. The initial content of the registry should be: PIM Flooding Mechanism Group Source Info Sub-TLV Types Type Name Reference ----------------------------------------------- 0-32767 Unassigned Can the purpose of this empty registry be explained? What protocol mechanism from this document uses code points from this registry?
I support the DISCUSS positions of Ketan Talaulikar and Med Boucadair.
Thanks to the authors for an interesting draft. I support many of the current discuss positions and don't have additional comments compared to the existing thorough readings and comments.
Thanks for the work done in this document, some non-blocking COMMENT though ### Med's DISCUSS I support Med's DISCUSS about the co-existence of GSH & GSI, i.e., which one has precedence ? ### What is the experiment ? Experimental docs are expected to describe the experiment with metrics of success. ### Why not 2 drafts ? This I-D actually has TWO major changes, i.e., sharing their fate :-( The PFM optimization would have greater chance to be approved by riding sole (i.e., without GSI). ### Unclear figure 1 Perhaps due to the HTML rendering, but is is unclear to me which is the actual topology depicted in Figure 1
Thanks to the authors and the WG for their work on this document. Thanks to the authors (Ananya) for the updates to address the technical portions of my DISCUSS ballot and most of the non-blocking comments. While I do not agree with some of the choices made, I respect the authors decision and the WG consensus. The remaining points and suggestions are on the original discussion email thread here: https://mailarchive.ietf.org/arch/msg/pim/5c9h2Z06d-c2_-ksTytvVEG5ljM/
Hi Ananya, Stig, and Francesco,
Thank you for the changes made in [1]. These address all points in my previous ballot [2].
Please find below a comment about the new version: There are some issues with the figure in Section 2.1 (type-dependent fields, Type Sub-TLV n layout). I suggest to consider the following changes:
OLD:
…
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | Type Sub-TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Sub-TLV 1 | Value Sub-TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| Type Sub-TLV n | Length Sub-TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Sub-TLV n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
…
Group Address: The multicast group address encoded as specified in
Section 4.9.1 of [RFC7761]. The length of this field depends on
the address family: 64 bits for IPv4 native encoding, 160 bits for
IPv6. Figure represents the IPv4 native encoding format.
Source Address: The unicast source address encoded as specified in
Section 4.9.1 of [RFC7761]. The length of this field depends on
the address family: 48 bits for IPv4 native encoding, 160 bits for
IPv6. Figure represents the IPv4 native encoding format.
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group Address (Encoded-Group format) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Address (Encoded-Unicast format) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | Type Sub-TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Sub-TLV 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Value Sub-TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ … ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Sub-TLV n | Length Sub-TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value Sub-TLV n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
…
Group Address: The multicast group address encoded as specified in
Section 4.9.1 of [RFC7761]. The length of this field depends on
the address family: 64 bits for IPv4 native encoding, 160 bits for
IPv6.
Source Address: The unicast source address encoded as specified in
Section 4.9.1 of [RFC7761]. The length of this field depends on
the address family: 48 bits for IPv4 native encoding, 160 bits for
IPv6.
To avoid confusion, you may add a note saying that “~” is used for variable-length fields + there is not alignment requirements for these fields.
Cheers,
Med
[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-pim-pfm-forwarding-enhancements-05&url2=draft-ietf-pim-pfm-forwarding-enhancements-06&difftype=--html
[2] https://mailarchive.ietf.org/arch/msg/pim/Nn7aPkBjQEzYQSsEYWdHcePp8z4/
I support all four currently open DISCUSS ballots, but otherwise have no additional objections to this Experimental draft proceeding.