Subject: [bess] FW: [Technical Errata Reported] RFC6625 (5605)

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 2 Mar 2020 04:01:04 +0000

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-masked]] 
Sent: Wednesday, January 16, 2019 2:36 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
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-masked]>

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