/
14-rfc-editor-feedback.txt
455 lines (336 loc) · 16.6 KB
/
14-rfc-editor-feedback.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
From wwwrun@rfc-editor.org Wed Dec 13 03:36:27 2017
Return-Path: <wwwrun@rfc-editor.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
faui40.informatik.uni-erlangen.de
X-Spam-Level:
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_PASS=-0.001,T_RP_MATCHES_RCVD=-0.01 autolearn=disabled version=3.4.0
X-Original-To: eckert+ietf@i4.informatik.uni-erlangen.de
Delivered-To: eckert+ietf@i4.informatik.uni-erlangen.de
Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 6555558C4EC
for <eckert+ietf@i4.informatik.uni-erlangen.de>; Wed, 13 Dec 2017 03:36:27 +0100 (CET)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id ADA1274D903
for <tte+ietf@cs.fau.de>; Wed, 13 Dec 2017 03:36:22 +0100 (CET)
Received: by rfc-editor.org (Postfix, from userid 30)
id 0D232B81521; Tue, 12 Dec 2017 18:35:55 -0800 (PST)
To: tarapore@att.com, rs1983@att.com, shep@cisco.com, tte+ietf@cs.fau.de, ramkri123@gmail.com
Subject: =?UTF-8?B?W0xCXSAgUXVlc3Rpb25zIGFib3V0IGRyYWZ0LWlldGYtbWJvbmVkLWludGVyZG9tYWluLXBlZXJpbmctYmNwLTE0LnR4dA==?=
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, gjshep@gmail.com, lenny@juniper.net, bclaise@cisco.com, warren@kumari.net, tim.chown@jisc.ac.uk
Content-type: text/plain; charset=UTF-8
Message-Id: <20171213023555.0D232B81521@rfc-editor.org>
Date: Tue, 12 Dec 2017 18:35:55 -0800 (PST)
X-Virus-Scanned: clamav-milter 0.99.2 at faui45
X-Virus-Status: Clean
Status: RO
Content-Length: 15056
Lines: 419
Dear authors,
While editing draft-ietf-mboned-interdomain-peering-bcp-14, we have the following questions.
Please reply so that your document will move forward in the publication process.
Thank you.
RFC Editor/lb
1) Section 1: We had trouble following this sentence,
because we do not see AD-1 referred to as the multicast source in
any other text in this document. Please clarify "AD-1 that this
document refers to as the multicast source."
Original:
To support that additional service, it is
recommended to use some method (outside the scope of this
document) by which the content from EUs is transmitted to the
application in AD-1 that this document refers to as the
multicast source and let it send out the traffic as IP
multicast.
2) Section 1: Because Section 4.2.2 does not mention IXPs,
we changed the citation to point to Section 4.2.4. Please let us
know if this is incorrect.
Original (the previous sentence is included for context):
The other case is that of a broadcast peering
point which is a common option in public Internet Exchange Points
(IXP). See Section 4.2.2 for more details about that option.
Currently:
The other case is that of a broadcast peering
point, which is a common option in public Internet Exchange Points
(IXPs). See Section 4.2.4 for more details.
3) Section 1: We could not find text in Section 2 that
relates to this sentence. Please confirm that "Section 2" is correct
here.
Original:
o As described in Section 2, the source IP address of the multicast
stream in the originating AD (AD-1) is known.
4) Section 3.1: BCP 145 (RFC 8085) does not mention
"rate adaption," and it appears that the RFCs cited in RFC 8085
don't mention it either. Please confirm that this citation is
correct and will be clear to readers who refer to it.
Original:
If this is not the case, then the multicast
traffic must support rate-adaption (see [BCP145]).
5) Section 3.2: Should "can or should not be enabled" be
"cannot be or should not be enabled," "can be enabled or should not
be enabled," or something else? Please clarify.
Original ("choosen" and "physcially" have been corrected):
Normally, this approach is choosen if the uBR physcially connected to
the peering link can or should not be enabled for IP multicast.
6) Section 3.2: For ease of the reader, we expanded "SAFI"
as "Subsequent Address Family Identifier." Please let us know if this
is incorrect.
Original:
The routing configuration is basically unchanged: Instead of BGP
(SAFI2) across the native IP multicast link between AD-1 and AD-2,
BGP (SAFI2) is now run across the GRE tunnel.
Currently:
The routing configuration is basically unchanged: instead of running
BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family
Identifier") across the native IP multicast link between AD-1 and
AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
7) Section 3.2: Does "the fully native multicast Use Case"
refer to a specific use case/section in this document, or is it used
generally?
Original:
o Highly efficient use of bandwidth in both domains, although not as
efficient as the fully native multicast Use Case.
8) Figure 5: "AMT Relay and Relays" looks odd. Should it
be "AMT Relays," or perhaps "AMT Gateways and Relays"?
Original:
Figure 5: AMT Tunnel Connecting AMT Relay and Relays
9) Section 4.1: "MBGP" is not used anywhere in RFC 4760.
"MBGP" can stand for "Multicast BGP" (per RFC 5760) or "Multiprotocol
BGP" (per RFC 6831). Please let us know how we should cite "MBGP"
here (and expand it in the legend for Figure 1) for ease of the
reader.
Original:
o Peering Point Protocol Support - Multicast protocols that will be
used for multicast delivery will need to be supported at these
points. Examples of protocols include eBGP [RFC4760] and MBGP
[RFC4760].
10) Section 4.1.1: We had trouble parsing this sentence.
Please clarify "and of not ..."
Original:
In many instances, multicast content delivery evolves from intra-
domain deployments where it is handled as a controlled network
service and of not complyng to congestion control principles.
Possibly:
In many instances, multicast content delivery evolves from
intra-domain deployments where it is handled as a controlled network
service and does not comply with congestion control principles.
11) Section 4.1.1: This sentence did not parse. We updated
it as follows. Please let us know if this is incorrect.
Original:
Because rate adaption in IP unicast video is
commonplace today because of ABR (Adaptive Bitrate Video), it is very
unlikely for this to happen though in reality with IP unicast.
Currently:
Note that because
rate adaption in IP unicast video is commonplace today due to the
availability of ABR (Adaptive Bitrate Video), it is very unlikely
that this will happen in reality with IP unicast.
12) Section 4.2.2: As there is no "Use Case 3.2.2," we
changed "3.2.2" to "3.2"; please let us know if this is incorrect.
Original:
If the interconnecting peering point is not multicast enabled and
both AD's are multicast enabled, then a simple solution is to
provision a GRE tunnel between the two AD's - see Use Case 3.2.2.
Currently:
If the interconnecting peering point is not multicast enabled and
both ADs are multicast enabled, then a simple solution is to
provision a GRE tunnel between the two ADs; see Use Case 3.2.
13) Section 4.2.3: This sentence does not parse. Please
clarify "and Anycast IP addresses process for Use Cases ..."
Original:
An illustrative example of a relay selection based on DNS queries and
Anycast IP addresses process for Use Cases 3.4 and 3.5 is described
here.
14) Section 4.2.4: We changed "do contract this content" to
"contact this content" per "The customer contacts content source" in
Section 4.3.2. Please let us know if this is incorrect.
Original:
Assume one or more IP multicast (S,G) traffic streams can be served
by both AD-1a and AD-1b, for example because both AD-1a and AD-1b do
contract this content from the same content source.
Currently:
Assume that one or more IP multicast (S,G) traffic streams can be
served by both AD-1a and AD-1b - for example, because both AD-1a and
AD-1b contact this content from the same content source.
15) Section 4.2.4: Does "upstreams" refer to upstream BRs,
upstream domains, upstream ADs, or something else? Please clarify.
Original:
3. The LAN has multiple upstreams, but they are federated and agree
on a consistent policy for IP multicast traffic across the LAN.
16) Section 4.2.4: To what does "above example" refer in
this sentence? Please clarify.
Original:
Another policy is that sources are redundantly
announced (problematic case mentioned in above example), but the
upstream domains also provide mutual operational insight to help
troubleshooting (outside the scope of this document).
17) Section 4.3.1: To what does "these" refer in this
sentence?
Original:
o Routing protocols as needed, e.g. configuring routers to support
these.
18) Section 4.3.1: Should "ISP backbones, peering and
access networks" be "ISP backbones, peering points, and access
networks," "ISP backbones, peering links, and access networks," or
something else?
Original:
Native multicast functionality is assumed to be available across many
ISP backbones, peering and access networks.
19) Section 4.3.2: To what does "propagate the issue" refer
in this sentence? Does it mean "communicate the problem," "convey the
customer's request," or something else? Please clarify.
Original:
The reason to specifically mention the need for AD-1 to initiate
interactions with AD-2 (and use some account for that), as opposed to
the opposite direction is based on the recommended workflow initiated
by customers (see Section 4.4): The customer contacts content source
(part of AD-1), when AD-1 sees the need to propagate the issue, it
will interact with AD-2 using the aforementioned guidelines.
20) Section 4.3.3: It appears that some words are missing
from this sentence (e.g., possibly a citation for another section
instead of "in before" and "the content source and on its behalf AD-1").
Please clarify.
Original:
The basic model as explained in before is that the content source and
on its behalf AD-1 take over primary responsibility for customer
experience and the AD-2's support this.
21) Section 4.4: Which use cases are referred to here?
Please clarify.
Original (the previous sentence is included for context):
o AD-2 may experience some problems in its network. For example,
for the AMT Use Cases, one or more AMT Relays may be experiencing
difficulties.
Possibly:
For example,
in Use Case 3.3 or Use Case 3.4, one or more AMT relays may be
experiencing difficulties.
22) Section 4.4: What does "CP" stand for in this phrase?
Original:
o Analysis of the problem information provided by the customer
(CP).
23) Section 6.1: This sentence does not parse. If the
suggested text is not correct, please clarify "solutions that
consider bandwidth consumed exist as vendor specific feature in
routers."
Original:
Simple solutions such as limiting
the maximum number of joined (S,G) per EU are readily available,
solutions that consider bandwidth consumed exist as vendor specific
feature in routers.
Suggested:
Simple solutions such as limiting
the maximum number of joined (S,G)s per EU are readily available;
solutions that take consumed bandwidth into account are available as
vendor-specific features in routers.
24) Section 6.1: We could not see in Use Case 3.4 how the
AMT relay in AD-1 is "that last replication point." Please confirm
that the reference to Use Case 3.4 is correct here.
Original:
Note that this is primarily a non-peering issue
in AD-2, it only becomes a peering issue if the peering-link itself
is not big enough to carry all possible content from AD-1 or in case
3.4 where the AMT relay in AD-1 is that last replication point.
25) Section 6.2: For ease of the reader, we expanded "OTT"
as "Over the Top." Please let us know if this is incorrect.
Original:
It is also
the model used in Internet OTT video delivery.
Currently:
It is also the model used in
Internet "Over the Top" (OTT) video delivery.
26) Section 6.2: This sentence does not parse. Please
clarify "only copy deliver thast is used in unicast."
Original (the previous sentence is included for context):
To mitigate this issue, the last replication point that is creating
(S,G) copies to EUs would need to permit those copies only after
authentication of EUs. This would establish the same authenticated
EU only copy deliver thast is used in unicast.
27) Section 6.2: Does "a separate network forwarding
authentication/authorization scheme" mean "a separate
traffic-forwarding authentication/authorization scheme,"
"a separate authentication/authorization scheme for forwarding
network traffic," or something else? Please clarify.
Original:
Such schemes
are technically not difficult to build and would avoid creating and
maintaining a separate network forwarding authentication/
authorization scheme decoupled from the end-to-end authentication/
authorization system of the application.
28) Section 6.3: Does "defined high bars" mean "defined
strict constraints," or something else? Please clarify.
Original:
In the case of a private peering link, IP multicast does not have
attack vectors on a peering link different from those of IP unicast,
but the content owner may have defined high bars against
unauthenticated copying of even the end-to-end encrypted content, and
in this case AD-1/AD-2 can agree on additional transport encryption
across that peering link.
29) Section 6.3: This sentence does not parse. Please
clarify "the information what content is being consumed."
Original ("the the" has been corrected):
It not only prohibits possible
"leakage" of content, but also to protects the the information what
content is being consumed in AD-2 (aggregated privacy protection).
30) Section 6.4: In this section,"(S,G)" is only mentioned
in the last sentence of the first paragraph of this section. Please
confirm that "this section" is correct here.
Original ("exhange" has been corrected):
Section 4.3.3 discusses exchange of log information, this section
discussed exchange of (S,G) information and Section 7 discusses
exhange of program information.
31) Section 6.4: It appears that either (1) a citation for
another section might be missing from this sentence or (2) "in before"
should be "before" (assuming that readers will know where to look for the
information). Please clarify "as discussed in before to protect it."
Original:
If any protocols used for the operational information exchange are
not easily secured at transport layer or higher (because of the use
of legacy products or protocols in the network), then AD-1 and AD-2
can also consider to ensure that all operational data exchange goes
across the same peering point as the traffic and use network layer
encryption of the peering point as discussed in before to protect it.
32) Section 7: We had trouble parsing this sentence. We
updated it as follows. Please let us know if this is incorrect.
Original:
AD-2 is not required to gain
additional insight into the user behavior through this process that
it would not already have without the service collaboration with AD-1
- unless AD-1 and AD-2 agree on it and get approval from the EU.
Currently:
AD-2 is not required to gain
additional insight into the user's behavior through this process
other than what it would already have without service collaboration
with AD-1, unless AD-1 and AD-2 agree on it and get approval from
the EU.
33) Please let us know if any changes are needed for the
following:
a) The following terms were used inconsistently in this document.
We chose to use the latter forms. Please let us know any objections.
"S,G" / (S,G)
AMT Relay / AMT relay (in text) (per RFC 7450)
AMT Gateway / AMT gateway (in text) (per RFC 7450)
GRE Tunnel / GRE tunnel (in text)
(per RFC 2784 and per more common usage in post-6000 published RFCs)
Native Multicast / native multicast (in text) (per RFC 7450)
Application Source (in text; 4 instances in Section 4.3.1) /
application source
group (or stream) id / group (or stream) ID
b) We changed the following variations to
"AS = multicast (e.g., content) Application Source." Please let us
know any objections.
AS = Application (e.g., Content) Multicast Source /
AS = Application Multicast Source /
AS = Application Source
Title : Use of Multicast Across Inter-Domain Peering Points
Author(s) : P. Tarapore, Ed.,
R. Sayko, G. Shepherd,
T. Eckert, Ed.,
R. Krishnan
Working Group Chair(s) : Greg Shepherd, Leonard Giuliano
Area Director(s) : Benoit Claise, Warren Kumari