[Softwires] Review of draft-ietf-softwire-mesh-multicast-20

[[e-mail]]

Hi,

I’ve just done a final review of -v20 of the draft. There’s still a few linguistic points and some clean ups that I think are needed. 

There’s also a couple of comments regarding points I would expect to get raised in later review phases, so it would be good if we could resolve these in advance.

Please see below.

Thanks,
Ian



Section 1.1
The paragraph beginning ‘Figure 1 shows…’ through to the end of the section shouldn’t be located under Requirements Language. Please move to Section 1.

Figure 1
Please use this cleaned up version of the diagram:


                +---------+        +---------+
                |         |        |         |  +--------+
                |  E-IP   |        |  E-IP   +—-+Source S|
                | Network |        | Network |  +--------+
                +----+----+        +——+------+
                     |                |
                  +--+-------+  +-----+----+
                  |          |  | Upstream |
                +-|   AFBR   +--+   AFBR   |-+
                | +----------+  +----------+ |
                |                            |  E-IP Multicast
                |      I-IP transit core     |  packets are forwarded
                |                            |  across the I-IP
                | +----------+  +----------+ |  transit core
                +-+Downstream+--+Downstream+-+
                  |   AFBR   |  |   AFBR   |
                  +--+-------+  +-------+--+
                     |                  |
                +----+----+        +----+----+
    +--------+  |         |        |         |  +--------+
    |Receiver+--+  E-IP   |        |  E-IP   +--+Receiver|
    +--------+  | Network |        | Network |  +--------+
                +---------+        +---------+


Figure 2.
Please use this cleaned up version of the diagram:
                +---------+        +---------+
                |  IPv4   |        |  IPv4   |  +--------+
                | Client  |        | Client  |--+Source S|
                | Network |        | Network |  +--------+
                +----+----+        +----+----+
                     |                  |
                  +--+-------+  +-------+--+
                  |          |  | Upstream |
                +-+   AFBR   +--+   AFBR   |-+
                | +----------+  +----------+ |
                |                            |
                |      IPv6 transit core     |
                |                            |
                | +----------+  +----------+ |
                +-+Downstream+--+Downstream+-+
                  |   AFBR   |  |   AFBR   |
                  +--+-------+  +-------+--+
                     |                  |
                +----+----+        +----+----+
    +--------+  |  IPv4   |        |  IPv4   |  +--------+
    |Receiver+--+ Client  |        | Client  +--+Receiver|
    +--------+  | Network |        | Network |  +--------+
                +---------+        +---------+

4.1.  Mechanism Overview
s/and is certainly separated from E-IP multicast state./and is separated from E-IP multicast state./
The word ‘certainly’ doesn’t really make sense here.

4.3. Source Address Mapping
Suggested reword for readability and to fix ‘WildCare’ spelling: 
o E-IP network supports ASM
      The (S,G) source list entry and the (*,G) source list entry differ
      only in that the latter has both the WildCard (WC) and RPT bits
      of the Encoded-Source-Address set, while with the former, the bits
      are cleared (See Section 4.9.5.1 of [RFC7761]).  As a result, the
      source list entries in (*,G) messages can be translated into source list
      entries in (S',G') messages by clearing both the WC and RPT bits
      at downstream AFBRs, and vice-versa for the reverse translation at
      upstream AFBRs.
——

I-D Nits is complaining about the group address word spacing in the figure.
Please use the following for figure 3:
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0-------------32--40--48--56--64--72--80--88--96-----------127|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                    mPrefix46                  | group address |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
---
4.4 Routing Mechanism
The following sentence is a a little unclear:
Since every IP address of upstream AFBR's E-IP interface is different from each other, every uPrefix46 that AFBR announces MUST be different.
Can it be simplified just to say?:
Every uPrefix46 that an AFBR announces MUST be unique.
----
Suggest that a paragraph break is inserted between ‘mesh unicast scenario.’ and ‘But as the “v4” field’ and that the word ‘But’ is removed.
——
s/BGP messages that are carried over I-IP, whose NLRI and NH are of E-IP address family./BGP messages that are carried over the I-IP, and whose NLRI and NH are of the E-IP address family./
—
5.2. I-IP (S’,G’) State Maintenance
s/It is possible that the I-IP transit core runs another non-transit I-IP PIM-SSM instance./It is possible that the I-IP transit core runs another, non-transit, I-IP PIM-SSM instance./
——

s/SHOULD NOT be used by other service provider/SHOULD NOT be used by another service provider/

A question that is bound to come up during the IESG review process - If this 
is a SHOULD NOT, what are the exceptions from a MUST NOT? i.e. under what
circumstances can two service providers use the same Well-Known prefix?

——
s/and the AFBR MUST translate this message back to PIMv4 message and process it./
and the AFBR MUST translate this message back to a PIMv4 message and process it./

Does this need to be a MUST requirement? Can’t the RFC2119 language be dropped here and just have ‘the AFBR translates this message back…’?

—
5.4. Inter-AFBR Signalling

s/Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT of (S,G)/Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT
   of (S,G)/

—

9. Security Considerations

Suggest that this is reformatted and worded as follows:

   The security concerns raised in [RFC4925] and [RFC7761] are
   applicable here.
   
   The additional workload associated with some schemes could be
   exploited by an attacker to perform a DDoS attack.
   
   Compared with [RFC4925], the security concerns SHOULD
   be considered more carefully: an attacker could potentially set up
   many multicast trees in the edge networks, causing too many multicast
   states in the core network.


Can any mitigation be offered against these attacks (would a BGP policy to only accept Well-Known prefix advertisements from trusted peers help?)