Hi WG, Just read another mail about Errata process <https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/> It reminds me about a very old Errata raised 1 year before. I have this confusion about the text of RFC6625 (as raised in the Errata) even longer before when the RFC8534 (updates this 6625) was in its very early version. Please the WG have a look and give comments/discussions/suggestions on it.
Thanks Jingrong -----Original Message----- From: RFC Errata System [mailto:[email protected]] Sent: Wednesday, January 16, 2019 2:36 PM To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Cc: Xiejingrong <[email protected]>; [email protected]; [email protected] Subject: [Technical Errata Reported] RFC6625 (5605) The following errata report has been submitted for RFC6625, "Wildcards in Multicast VPN Auto-Discovery Routes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5605 -------------------------------------- Type: Technical Reported by: Jingrong Xie <[email protected]> Section: 3.2.1 Original Text ------------- - If there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that route. - Otherwise, if there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM multicast group address, then (C-S,C-G) matches that route. - Otherwise, if there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM multicast group address, then (C-S,C-G) matches that route. - Otherwise, if there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches that route. Corrected Text -------------- - If there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that route. - If there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM multicast group address, then (C-S,C-G) matches that route too. - If there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM multicast group address, then (C-S,C-G) matches that route too. - If there is an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches that route too. Notes ----- The 'Match for data reception' is an behavior on the MVPN receiver-site PE. If an SPMSI A-D route is matched for data reception, it means that the receiver-site PE will respond to this SPMSI A-D route, either send a responded Leaf A-D route in case there is an explicit-tracking flag (LIR or LIRpF), or join the PMSI tunnel in the SPMSI A-D route in case the tunnel type is mLDP/PIM etc. This usage of 'match for data reception' is not explicitly explained in this RFC but it is used in <draft-ietf-bess-mvpn-expl-track-13>. There is clear inclusive-selective relationship between S-PMSI A-D (*,*) and S-PMSI A-D(S,G). Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site PE with a (C-S,C-G) state should keep its join state on both the S-PMSI A-D (*,*) and S-PMSI A-D(S,G), and setup the 'reception state' on both the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel. So the 'match for reception' should be one or more SPMSI A-D routes. The 'if/othersize/othersize' sentences make the wrong meaning. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6625 (draft-ietf-l3vpn-mvpn-wildcards-02) -------------------------------------- Title : Wildcards in Multicast VPN Auto-Discovery Routes Publication Date : May 2012 Author(s) : E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
