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?)
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
