Subject: Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

From: "杨术" <[email-masked]>
Date: Sun, 2 Jun 2019 23:30:24 +0800

Dear Benjamin,

Thank you for your helpful and detailed comments, we reply as following, 

> Section 1

> I think you should provide a brief summary of what "(S,G) states" are in
 
> this document, as well as the reference.

We added the text “(S,G) states, which is source specific states related with 
 
a specified multicast group [RFC7761][RFC7899].”

> Section 3

>    o Address Family Border Router (AFBR) - A router interconnecting two
 
>    or more networks using different IP address families.  Besides, in
 
>    the context of softwire mesh multicast, the AFBR runs E-IP and I-IP

> nit: maybe s/Besides/Additionally/?

We have replaced it.

> nit: using "upper reaches" and "lower reaches" is still basically the same
 
> metaphor as upstream/downstream.  I guess "closer to the source" and
 
> "closer to a receiver" might be different, but offer no opinion on whether
 
> it would be better.

We have changed them to “closer to”.

> Section 5.2/5.3

> Please expand SSM and ASM on first usage.

We have expanded them.

> Section 5.4

>    To achieve this, every AFBR MUST announce the address of one of its
 
>    E-IPv4 interfaces in the "v4" field alongside the corresponding
 
>    uPreifx64.  The announcement MUST be sent to the other AFBRs through
 
>    MBGP [RFC4760].  Every uPrefix46 that an AFBR announces MUST be
 
>    unique.  "uPrefix46" is an IPv6 prefix, and the distribution
 
>    mechanism is the same as the traditional mesh unicast scenario.

> I am not very familiar with this space, and just wanted to check that both
 
> "uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64"
 
> being a typo).

We have modified the typo.

>    When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be
 
>    generated according to the format specified in Figure 3, with the
 
>    "source address" field set to * (wildcard value).  The translated

> There is no "source address" field in Figure 3.

We deleted the “according to the format specified in Figure 3”.

>    message will be forwarded to the corresponding upstream AFBR.  Since
 
>    every PIM router within a PIM domain MUST be able to map a particular
 
>    multicast group address to the same RP (see Section 4.7 of
 
>    [RFC7761]), when the upstream AFBR checks the "source address" field
 
>    of the message, it finds the IPv4 address of the RP, and ascertains
 
>    that this is originally a (*,G) message.  This is then translated
 
>    back to the (*,G) message and processed.

> I'm failing to find where the downstream AFBR is setting the source address
 
> to that of the RP; presumably this just means I'm confused about how this
 
> part works.

We modified this part as following, 

Since every PIM router within a PIM domain MUST be
 
   able to map a particular multicast group address to the same RP when
 
   the source address is set to wildcard value (see Section 4.7 of
 
   [RFC7761]), when the upstream AFBR checks the "source address" field
 
   of the message, it finds the IPv4 address of the RP, and ascertains
 
   that this is originally a (*,G) message.  This is then translated
 
   back to the (*,G) message and processed.

> Section 6.4

>    Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT
 
>    of (S,G), and decided to perform an SPT switchover.  According to

> Is it the AFBR that has joined the (E-IP) group and decided to switchover,
 
> or some system in the client network?

Some client will initiate the switchover, and cause AFBR to switch over. We added
 
a reference as following:

“Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT of (S,G), 
 
and decided to perform an SPT switchover (see Section 4.2.1 of [RFC7761]).”

> Section 8

>    In Figure 5, the semantics of fields "PIM Ver", "Type", "Reserved",
 
>    and "Checksum" can be referred in Section 4.9 of [RFC7761].
 
>    IPv4 Group Address (Encoded-Group format): The encoded-group format
 
>    of the IPv4 group address described in Section 4.2.

>    IPv4 Source Address (Encoded-Group format): The encoded-unicast
 
>    format of the IPv4 source address described in Section 4.3.

>    IPv6 Group Address (Encoded-Group format): The encoded-group format
 
>    of the IPv6 group address described in Section 4.2.

>    IPv6 Source Address (Encoded-Group format): The encoded-unicast
 
>    format of the IPv6 source address described in Section 4.3.

> This document has no Section 4.2 or 4.3 (and those sections of RFC 7761 do
 
> not seem appropriate here, either).

We have modified the pointer.

> Section 9

> "MUST [...] follow the requirements mentioned in
 
> [I-D.ietf-intarea-tunnels]" seems like it needs a normative reference.
 
> "MUST [...] allow the use of encapsulation mechanisms mentioned in
 
> [RFC4925]" would seem to do the same.

We change these references to be normative. 

> Section 10

> It may be worth calling out the "interface agent" as being an additional
 
> workload susceptible to DDoS.

> It is true that the trusted nature of the BGP peer is what is relevant for
 
> deciding to accept Well-Known prefix advertisements, but perhaps there is
 
> room to mention the potential use of cryptographic methods for
 
> authenticating the peer so as to have increased confidence that such trust
 
> is properly placed.

We took these into considerations in this section.

Best Regards,

Shu Yang

------------------

杨术

欧德蒙科技有限公司

This message may contain privileged and confidential information only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately. 

------------------ Original ------------------
From:  "Benjamin Kaduk"<[email-masked]>;
Date:  Thu, Sep 27, 2018 08:50 AM
To:  "The IESG"<[email-masked]>; 
Cc:  "softwires"<[email-masked]>; "draft-ietf-softwire-mesh-multicast"<[email-masked]>; "softwire-chairs"<[email-masked]>; 
Subject:  [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-softwire-mesh-multicast-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting No Objection instead of Discuss, but I think this document
has a few things that need to be resolved before publication.  In
particular:

I'm concerned that the informative references may actually need to be
normative references, but not quite enough to cross my Discuss threshold.
See my comments on Section 9 for details.

There are several things that look like internal references but are not
resolvable (see per-section comments).

Section 1

I think you should provide a brief summary of what "(S,G) states" are in
this document, as well as the reference.

Section 3

   o Address Family Border Router (AFBR) - A router interconnecting two
   or more networks using different IP address families.  Besides, in
   the context of softwire mesh multicast, the AFBR runs E-IP and I-IP

nit: maybe s/Besides/Additionally/?

nit: using "upper reaches" and "lower reaches" is still basically the same
metaphor as upstream/downstream.  I guess "closer to the source" and
"closer to a receiver" might be different, but offer no opinion on whether
it would be better.

Section 5.2/5.3

Please expand SSM and ASM on first usage.

Section 5.4

   To achieve this, every AFBR MUST announce the address of one of its
   E-IPv4 interfaces in the "v4" field alongside the corresponding
   uPreifx64.  The announcement MUST be sent to the other AFBRs through
   MBGP [RFC4760].  Every uPrefix46 that an AFBR announces MUST be
   unique.  "uPrefix46" is an IPv6 prefix, and the distribution
   mechanism is the same as the traditional mesh unicast scenario.

I am not very familiar with this space, and just wanted to check that both
"uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64"
being a typo).

   When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be
   generated according to the format specified in Figure 3, with the
   "source address" field set to * (wildcard value).  The translated

There is no "source address" field in Figure 3.

   message will be forwarded to the corresponding upstream AFBR.  Since
   every PIM router within a PIM domain MUST be able to map a particular
   multicast group address to the same RP (see Section 4.7 of
   [RFC7761]), when the upstream AFBR checks the "source address" field
   of the message, it finds the IPv4 address of the RP, and ascertains
   that this is originally a (*,G) message.  This is then translated
   back to the (*,G) message and processed.

I'm failing to find where the downstream AFBR is setting the source address
to that of the RP; presumably this just means I'm confused about how this
part works.

Section 6.4

   Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT
   of (S,G), and decided to perform an SPT switchover.  According to

Is it the AFBR that has joined the (E-IP) group and decided to switchover,
or some system in the client network?

Section 8

   In Figure 5, the semantics of fields "PIM Ver", "Type", "Reserved",
   and "Checksum" can be referred in Section 4.9 of [RFC7761].
   IPv4 Group Address (Encoded-Group format): The encoded-group format
   of the IPv4 group address described in Section 4.2.

   IPv4 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv4 source address described in Section 4.3.

   IPv6 Group Address (Encoded-Group format): The encoded-group format
   of the IPv6 group address described in Section 4.2.

   IPv6 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv6 source address described in Section 4.3.

This document has no Section 4.2 or 4.3 (and those sections of RFC 7761 do
not seem appropriate here, either).

Section 9

"MUST [...] follow the requirements mentioned in
[I-D.ietf-intarea-tunnels]" seems like it needs a normative reference.
"MUST [...] allow the use of encapsulation mechanisms mentioned in
[RFC4925]" would seem to do the same.

Section 10

It may be worth calling out the "interface agent" as being an additional
workload susceptible to DDoS.

It is true that the trusted nature of the BGP peer is what is relevant for
deciding to accept Well-Known prefix advertisements, but perhaps there is
room to mention the potential use of cryptographic methods for
authenticating the peer so as to have increased confidence that such trust
is properly placed.

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Mon, 3 Jun 2019 05:33:17 +0000

Hi Shu, all,

Please see inline.

Cheers,
Med

De : Softwires [mailto:[email-masked]] De la part de ??
Envoyé : dimanche 2 juin 2019 17:30
À : Benjamin Kaduk; The IESG
Cc : softwires; draft-ietf-softwire-mesh-multicast; softwire-chairs
Objet : Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

Dear Benjamin,

[Med] Given that this document relies on RFC8114 to construct multicast prefixes (and other matters), I suggest to use the same terms as those defined in RFC8114:

   mPrefix64:  a dedicated multicast IPv6 prefix for constructing

      IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two

      types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or

      SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode

      [RFC4607<https://tools.ietf.org/html/rfc4607>].  The size of this prefix is /96.

         Note: "64" is used as an abbreviation for IPv6-IPv4

         interconnection.

   uPrefix64:  a dedicated IPv6 unicast prefix for constructing

      IPv4-embedded IPv6 unicast addresses [RFC6052<https://tools.ietf.org/html/rfc6052>].  This prefix may

      be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-

      Specific Prefix (NSP).

…

[Med] I’m not sure this is the right approach. Do you really need draft-ietf-intarea-tunnels? IMHO, that section can be replaced with a sentence pointing to rfc5565#section-8.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 3 Jun 2019 15:35:39 -0700

> Thank you for your helpful and detailed comments, we reply as following, 

Thanks; these changes all seem reasonable to me (as to Med's follow-up to a
couple of points, if you want to make those changes as well).

-Ben