Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-20
Hi, Ian, Thank you very much for your comments. We will do our best to revise the draft. Mingwei 2018-05-17 Mingwei Xu 发件人： ianfarrer 发送时间： 2018-05-16 19:41:40 收件人： draft-ietf-softwire-mesh-multicast 抄送： Softwires-wg list 主题： [Softwires] Review of draft-ietf-softwire-mesh-multicast-20 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
[Softwires] Review of draft-ietf-softwire-mesh-multicast-20
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 tran
