From nobody Fri Dec 1 12:09:40 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 122751241F5; Fri, 1 Dec 2017 12:09:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk CC: stig@venaas.com, pim-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-pim-yang@ietf.org, Stig Venaas , pim@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151215897402.2880.9475243692426302877.idtracker@ietfa.amsl.com> Date: Fri, 01 Dec 2017 12:09:34 -0800 Archived-At: Subject: [pim] Last Call: (A YANG data model for Protocol-Independent Multicast (PIM)) to Proposed Standard X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 20:09:34 -0000 The IESG has received a request from the Protocols for IP Multicast WG (pim) to consider the following document: - 'A YANG data model for Protocol-Independent Multicast (PIM)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-12-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure and manage Protocol Independent Multicast (PIM) devices. The model covers the PIM protocol configuration, operational state, and event notifications data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-yang/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pim-yang/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-bjorklund-netmod-rfc7223bis: A YANG Data Model for Interface Management (None - IETF stream) draft-acee-netmod-rfc8022bis: A YANG Data Model for Routing Management (NDMA Version) (None - ) From nobody Wed Dec 6 07:12:39 2017 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D184A126DD9; Wed, 6 Dec 2017 07:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgmhikcKxFhs; Wed, 6 Dec 2017 07:12:35 -0800 (PST) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9788A128BBB; Wed, 6 Dec 2017 07:12:31 -0800 (PST) Received: by mail-oi0-x244.google.com with SMTP id x20so2730671oix.12; Wed, 06 Dec 2017 07:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=Mbin3gDV7m2w1HAeakPtozMQ1AjOddYgDSqGWKq2R38=; b=E9EvehEIe3WqCjoVsFSOZVmBuwWHyAA80MJgSeZ5saLSPEWEL080VDcZm61kjd2ts1 f0t4QSDq0m6obLiPpiw3eOC720Phzok6mxW5XIO7ev6Iaj1pkaNfiaQTZ9QL8Rye7v6D zRE8Mf8A4KcWYqAv14vFUCBma6NRX+yw8SHQjPctD+juCU6ti97rYA+snw2PkJoHa6dK iV2bxf3VSZjxJjU5PMmdOeu725lH9XVAapeeub62lBy0APY1S3PbStRLVCrIL0PC6btw xHWcQx+B97CzMRrFgya7feJ362r46LVOrq1oAAzXNOURYJAXdxQs/44M7O3gpEk4/bOi 3yVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=Mbin3gDV7m2w1HAeakPtozMQ1AjOddYgDSqGWKq2R38=; b=m9spPbG8tkCySSunpaX96p081GuW0SH89h/dMcmuyTY8uUxOgZfSlpnajsjdrsxJhx MF0cLz9AG8kiv78XcfhR4iy7kqN8Va3dD8NLyv4vvq4xzf8wzw8KrrexG5tL3uML3nvn X5i9nrqtWdnn4f1p1A4iNes+R+67IAEdo9IoqxfWSN6U/qDapVzgh3vIl4LPwhbVD+02 J+EAs4wR6qS53ly3VBUmkv4L7CtUt9E1R38YYAJK/eY0uBHHSx5JcuFAxBMv3n4QXWqg dw0clH5qj1Ny8lP5rraO8Leg37icKEwb+LnaqxoG43bHcxo+JewmM5L4/NzriGOZNC3G 1NUA== X-Gm-Message-State: AJaThX5NEVinExSvjM5SMx6e1fWWFW+0MpApqPlJRqLQ/9YP5ozDx92C 8+DzqdvDzuUa0FSHK9BPTzV3HaVYfzjlXaQBmnc= X-Google-Smtp-Source: AGs4zMZnrMIanbfxawIn79FKV9DyxiP1ex8gCHsj1L7AjqjsYz1Pvwdn2Qdr9vkzQ+Rud2MFkE7RqmOWKNge1SLJiEU= X-Received: by 10.202.114.88 with SMTP id p85mr19011731oic.214.1512573150679; Wed, 06 Dec 2017 07:12:30 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 07:12:30 -0800 From: Alvaro Retana X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 07:12:30 -0800 Message-ID: To: draft-ietf-pim-source-discovery-bsr@ietf.org, pim-chairs@ietf.org, pim@ietf.org Cc: Mike McBride Content-Type: multipart/alternative; boundary="001a11c1742057d8ef055fad613a" Archived-At: Subject: [pim] AD Review of draft-ietf-pim-source-discovery-bsr-06 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:12:38 -0000 --001a11c1742057d8ef055fad613a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors/Chairs/WG: I just finished reading this document. In general, this is a straight forward mechanism, but it needs some more details around the specification (even if its Status is Experimental). What is the experiment? I am happy that the mechanism has been tested in the field (from Section 2) =E2=80=94 the question here is: why is this docu= ment Experimental? What do you hope to learn from experimenting with this proposal? The answer could be as simple as =E2=80=9Cto gain experience in = other types of deployments=E2=80=9D (which ones?) to something like =E2=80=9Cexpe= rimentation with different holdtimes and origination intervals=E2=80=9D (just making that up= =E2=80=94 obviously!). Maybe it is to get experience and/or more information to answer some of the questions below. ;-) I am also asking the question about the Status because this document defines two related, but different things: PFM ("generic mechanism that can flood any kind of information=E2=80=9D) and the GSH TLV (which is one of th= e potential applications for PFM). Do you (the WG) want to tie the source discovery experiment to the generic flooding mechanism? I didn=E2=80=99t f= ind other drafts referencing this one, indicating that there are no other published extensions =E2=80=94 so maybe the answer to the question is =E2= =80=9CYes=E2=80=9D. Note that I=E2=80=99m generally ok with the Experimental Status, I just wan= t to better understand the experiment and confirm that you considered the 2 technical specifications independently. There is one more reason I=E2=80=99m asking about the Status: the No-Forwa= rd bit (in 3.1) is assigned out of a field that rfc7761 marks as Reserved ("Set to zero on transmission. Ignored upon receipt.=E2=80=9D). An Experimental do= cument can=E2=80=99t update a Standards Track one (and rfc7761 is now an Internet Standard) =E2=80=94 not to mention that this Reserved field in the header c= ommon to all PIM messages. As far as I can tell, no other PIM message has used the Reserved field for anything, and the application here seems very specific to PFM (or even PFM-SA) =E2=80=94 so there are a few different ways forward= to allow this document to use bits in the Reserved field. In general the options (that pop into my head right now) are: (1) Define a registry that specifies how the Reserved bits are to be allocated (common to all PIM messages). Some of those bits could be message-specific. (2) Declare the Reserved bits message-specific=E2=80=A6so that every messag= e can make use of them as it sees fit. Then each message (PFM, for example) can assign the bits (and define how others could be assigned). (3) The No-Forward bit could be defined elsewhere (not in the common header) =E2=80=94 this is the easy solution. (4) =E2=80=A6there might be other options=E2=80=A6 In the meantime, I have other comments below. Thanks! Alvaro. Major: M1. In 3.1. (PFM message format): "PIM Version: Reserved, Checksum Described in [RFC7761].=E2=80=9D I guess you mean that all 3 fields are de= scribed in rfc7761, right? M2. From 3.2.1. (Initial checks): M2.1. What does it mean to have an =E2=80=9Cactive Hello state=E2=80=9D? I= can guess, but no one should have to. M2.2. =E2=80=9C...the interface MUST NOT be an administrative boundary for = PFM=E2=80=9D =E2=80=94 what is an administrative boundary interface? How is the boundary different for PFM (when compared to PIM)? Section 3. (A generic PIM flooding mechanism) says that PFM "can flood...throughout a PIM domain. It is not necessarily a domain though, it depends on the administrative boundaries being configured=E2=80=9D, but no details of what that means are provided anywhere. M2.3. For my own education, why is this check neede: =E2=80=9CIf No-Forward= is set, we MUST have restarted within 60 seconds.=E2=80=9D? BTW, =E2=80=9CMUST ha= ve=E2=80=9D doesn=E2=80=99t make sense Normatively. M3. In 3.2.2. (Processing and forwarding of PFM messages): =E2=80=9C...TLVs= in the received message...if the most significant bit in the type field is set (the type value is larger than 32767) and we do not support the type, then that particular type should be omitted from the forwarded messages=E2=80=9D= . I=E2=80=99m not sure if you mean that Types > 32767 should be used if you want every node to be aware (which is why TLVs are not forwarded if not supported), OR, that the Types are really 15 bits long and that the most significant bit is reserved to indicate the forwarding behavior. In either case, the text here, in the Type description in 3.1 and in the IANA Considerations section should be updated to clarify. M4. From 4.1. (Group Source Holdtime TLV): "Length: The length of the value.=E2=80=9D=E2=80=A6in octets, bytes, bits?? M5. Section 4.2. (Originating PFM messages): M5.1. "Note that this address SHOULD be routeable due to RPF checking.=E2= =80=9D What are the conditions when it is ok for the address not to be routable? Why is the SHOULD not a MUST? M5.2. I think you need an =E2=80=9COriginating PFM Messages=E2=80=9D Sectio= n as 3.* to talk about origination in the general case. For example, should origination always be periodic, does it depend on the type of TLVs carried, what if different TLVs have different periods, can the receiver infer anything from not receiving a TLV (and what should the sender do about it), etc. ?? [Suggestion: rename 4.2 as =E2=80=9COriginating GSH TLVs=E2=80=9D.] M6. Section 4.3. (Processing GSH TLVs) M6.1. "A router that receives a PFM message containing GSH TLVs SHOULD parse the message and store each of the GSH TLVs as SG mappings with a holdtimer started with the advertised holdtime.=E2=80=9D What are the cond= itions where a router wouldn=E2=80=99t parse and store? IOW, why is this SHOULD n= ot a MUST? M6.2. "For each group that has directly connected receivers, this router SHOULD send PIM (S,G) joins for all the SG mappings advertised in the message for the group.=E2=80=9D Again, why is this SHOULD not a MUST? Whe= n would the router not send a join? M6.3. [minor] "For instance, if there is a large number of sources for a group, there may be multiple PFM messages, each message containing a different list of sources for the group.=E2=80=9D s/PFM messages/GSH TLVs.= As I mentioned above, I think you need a section talking about PFM-specific behavior and this one about GSH-specific behavior. M7. Section 5. (Security Considerations) M7.1. "The security considerations are mainly similar to what is documented in [RFC5059].=E2=80=9D =E2=80=9CMainly similar=E2=80=9D??? What is differ= ent? Just one item that jumped at me: rfc5059 talks about the risk of DoS using IPsec, but rfc7761 took IPsec authentication out of PIM-SM. I wonder what would be easier/clearer: to mention the exceptions wrt rfc5059 or to roll your own considerations based on rfc7761. Either way would work for me, but (to avoid rehashing the rfc7761 discussions) making rfc7761 a significant part of the security considerations would be good. M7.2. "PFM packets must only be accepted from a PIM neighbor.=E2=80=9D Sho= uld that =E2=80=9Cmust=E2=80=9D be a MUST? M7.3. Because PFM "can flood any kind of information throughout a PIM domain=E2=80=9D, are there additional considerations around that? I=E2=80= =99m thinking privacy, for example: if I can really flood anything, then I could put in location information of the sources/receivers, which could reveal things about them (not to mention whatever =E2=80=9Cany kind of information=E2=80= =9D could include). You might want to rethink the description of the expected use scope for PFM. M8. References: rfc5226 has been obsoleted by rfc8126 =E2=80=94 this refer= ence should be Normative. Minor: P1. In 4.5. (Resiliency to network partitioning): "As soon as the network heals, the SG Mappings are re-flooded into the other partition(s) and other receivers can join to the newly learned sources.=E2=80=9D It is not clear = in the text in Section 3.2.2. (Processing and forwarding of PFM messages) that this result would be achieved as it says that "After processing, we forward the message.=E2=80=9D, and not that the messages are forwarded when a new n= eighbor is found (which would be the equivalent of the network healing). Nits: N1. Please don=E2=80=99t use =E2=80=9Cwe=E2=80=9D throughout the specificat= ion. For example: instead of "After processing, we forward the message.=E2=80=9D, perhaps =E2= =80=9CAfter processing, the message is forwarded.=E2=80=9D N2. The numbers on top of the packet formats are misaligned. N3. s/[N]o-Forward bit/N bit (No-Forward) Note that No-Forward is used later in the text. --001a11c1742057d8ef055fad613a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors/Chairs/WG:

I just finished reading this document.=C2=A0 I= n general, this is a straight forward mechanism, but it needs some more det= ails around the specification (even if its Status is Experimental).

What is the experiment?=C2= =A0 I am happy that the mechanism has been tested in the field (from Sectio= n 2) =E2=80=94 the question here is: why is this document Experimental?=C2= =A0 What do you hope to learn from experimenting with this proposal?=C2=A0 = The answer could be as simple as =E2=80=9Cto gain experience in other types= of deployments=E2=80=9D (which ones?) to something like =E2=80=9Cexperimen= tation with different holdtimes and origination intervals=E2=80=9D (just ma= king that up =E2=80=94 obviously!).=C2=A0 Maybe it is to get experience and= /or more information to answer some of the questions below. ;-)

I am also asking the question about th= e Status because this document defines two related, but different things: P= FM ("generic mechanism that can flood any kind of information= =E2=80=9D) and the GSH TLV (which is one of the potential applications for = PFM).=C2=A0 Do you (the WG) want to tie the source discovery experiment to = the generic flooding mechanism?=C2=A0 I didn=E2=80=99t find other drafts re= ferencing this one, indicating that there are no other published extensions= =E2=80=94 so maybe the answer to the question is =E2=80=9CYes=E2=80=9D.

Note that I=E2=80=99m generally ok wi= th the Experimental Status, I just want to better understand the experiment= and confirm that you considered the 2 technical specifications independent= ly.

There is one more reason I=E2= =80=99m asking about the Status: =C2=A0the No-Forward bit (in 3.1) is assig= ned out of a field that rfc7761 marks as Reserved ("Set to zero on tra= nsmission.=C2=A0 Ignored upon receipt.=E2=80=9D).=C2=A0 An Experimental doc= ument can=E2=80=99t update a Standards Track one (and rfc7761 is now an Int= ernet Standard) =E2=80=94 not to mention that this Reserved field in the he= ader common to all PIM messages.=C2=A0 As far as I can tell, no other PIM m= essage has used the Reserved field for anything, and the application here s= eems very specific to PFM (or even PFM-SA) =E2=80=94 so there are a few dif= ferent ways forward to allow this document to use bits in the Reserved fiel= d.=C2=A0 In general the options (that pop into my head right now) are:

(1) Define a registry that specifies ho= w the Reserved bits are to be allocated (common to all PIM messages).=C2=A0= Some of those bits could be message-specific.

(2) Declare the Reserved bits message-specific=E2=80=A6so that = every message can make use of them as it sees fit.=C2=A0 Then each message = (PFM, for example) can assign the bits (and define how others could be assi= gned).

(3) The No-Forward bit could= be defined elsewhere (not in the common header) =E2=80=94 this is the easy= solution.

(4) =E2=80=A6there might= be other options=E2=80=A6


In the meantime, I have= other comments below.

Thanks!

Alvaro.



Major:<= /div>

M1. In=C2=A03.1. (PFM= message format): "PIM Version: =C2=A0 Reserved, Checksum Described in= [RFC7761].=E2=80=9D =C2=A0I guess you mean that all 3 fields are described= in rfc7761, right? =C2=A0


M2. From=C2=A03.2.1. (I= nitial checks):=C2=A0

M2.1. What does it mean to have an =E2=80=9Cactive Hello state=E2=80=9D?= =C2=A0 I can guess, but no one should have to.

M2.2. =E2=80=9C...the interface MUST NOT be an a= dministrative boundary for PFM=E2=80=9D =E2=80=94 what is an administrative= boundary interface?=C2=A0 How is the boundary different for PFM (when comp= ared to PIM)?=C2=A0 Section=C2=A03. (A generic PIM flooding mechanism) says= that PFM "can flood...throughout a PIM domain.=C2=A0 It is not necess= arily a domain though, it depends on the administrative boundaries being co= nfigured=E2=80=9D, but no details of what that means are provided anywhere.=

M2.3. For my own education, why = is this check neede: =E2=80=9CIf No-Forward is set, we MUST have restarted = within 60 seconds.=E2=80=9D? =C2=A0 BTW, =E2=80=9CMUST have=E2=80=9D doesn= =E2=80=99t make sense Normatively.


M3. In=C2=A03.= 2.2. (Processing and forwarding of PFM messages): =E2=80=9C...TLVs in the r= eceived message...if the most significant bit in the type field is set (the= type value is larger than 32767) and we do not support the type, then that= particular type should be omitted from the forwarded messages=E2=80=9D.=C2= =A0 I=E2=80=99m not sure if you mean that Types > 32767 should be used i= f you want every node to be aware (which is why TLVs are not forwarded if n= ot supported), OR, that the Types are really 15 bits long and that the most= significant bit is reserved to indicate the forwarding behavior.=C2=A0 In = either case, the text here, in the Type description in 3.1 and in the IANA = Considerations section should be updated to clarify.


M4. From=C2=A04.1. (Group Source Holdtime TLV): &qu= ot;Length: =C2=A0 The length of the value.=E2=80=9D=E2=80=A6in octets, byte= s, bits??

M5. Section 4.2. (Originating PFM messages):

M5.1. "Note that this address SHOULD be ro= uteable due to RPF checking.=E2=80=9D =C2=A0What are the conditions when it= is ok for the address not to be routable?=C2=A0 Why is the SHOULD not a MU= ST?

M5.2. I think you need an =E2= =80=9COriginating PFM Messages=E2=80=9D Section as 3.* to talk about origin= ation in the general case.=C2=A0 For example, should origination always be = periodic, does it depend on the type of TLVs carried, what if different TLV= s have different periods, can the receiver infer anything from not receivin= g a TLV (and what should the sender do about it), etc. ?? =C2=A0[Suggestion= : rename 4.2 as =E2=80=9COriginating GSH TLVs=E2=80=9D.]


M6. Section=C2=A04.3. (Processing GSH TLVs)

M6.1. "A router that receives a PFM message containing= GSH TLVs SHOULD parse the message and store each of the GSH TLVs as SG map= pings with a holdtimer started with the advertised holdtime.=E2=80=9D =C2= =A0What are the conditions where a router wouldn=E2=80=99t parse and store?= =C2=A0 IOW, why is this SHOULD not a MUST?

M6.2. "For each group that has directly connected receivers, t= his router SHOULD send PIM (S,G) joins for all the SG mappings advertised i= n the message for the group.=E2=80=9D =C2=A0Again, why is this SHOULD not a= MUST?=C2=A0 When would the router not send a join?

M6.3. [minor] "For instance, if there is a large numb= er of sources for a group, there may be multiple PFM messages, each message= containing a different list of sources for the group.=E2=80=9D =C2=A0s/PFM= messages/GSH TLVs. =C2=A0 As I mentioned above, I think you need a section= talking about PFM-specific behavior and this one about GSH-specific behavi= or.


M7. Section=C2=A05. (Security Con= siderations)
=
M7.1. "The security considerations are mainly similar to what is documented i= n [RFC5059].=E2=80=9D =C2=A0=E2=80=9CMainly similar=E2=80=9D???=C2=A0 What = is different?=C2=A0 Just one item that jumped at me: rfc5059 talks about th= e risk of DoS using IPsec, but rfc7761 took IPsec authentication out of PIM= -SM.=C2=A0 I wonder what would be easier/clearer: to mention the exceptions= wrt rfc5059 or to roll your own considerations based on rfc7761.=C2=A0 Eit= her way would work for me, but (to avoid rehashing the rfc7761 discussions)= making rfc7761 a significant part of the security considerations would be = good.

M7.2. "PFM packets must = only be accepted from a PIM neighbor.=E2=80=9D =C2=A0Should that =E2=80=9Cm= ust=E2=80=9D be a MUST?

M7.3. Becau= se PFM "can flood any kind of information throughout a PIM domain=E2= =80=9D, are there additional considerations around that?=C2=A0 I=E2=80=99m = thinking privacy, for example: if I can really flood anything, then I could= put in location information of the sources/receivers, which could reveal t= hings about them (not to mention whatever =E2=80=9Cany kind of information= =E2=80=9D could include).=C2=A0 You might want to rethink the description o= f the expected use scope for PFM.


M8. References= : =C2=A0rfc5226 has been obsoleted by rfc8126 =E2=80=94 this reference shou= ld be Normative.


=
Minor:
=

P1. In 4.5. (Resiliency to netw= ork partitioning): "As soon as the network heals, the SG Mappin= gs are re-flooded into the other partition(s) and other receivers can join = to the newly learned sources.=E2=80=9D =C2=A0It is not clear in the text in= Section=C2=A03.2.2. (Processing and forwarding of PFM messages) that this = result would be achieved as it says that "After processing, we forward= the message.=E2=80=9D, and not that the messages are forwarded when a new = neighbor is found (which would be the equivalent of the network healing).


Nits:

N1. Please don=E2=80=99t use =E2=80=9Cwe=E2= =80=9D throughout the specification.=C2=A0 For example: instead of "Af= ter processing, we forward the message.=E2=80=9D, perhaps =E2=80=9CAfter pr= ocessing, the message is forwarded.=E2=80=9D

N2. The numbers on top of the packet formats are mi= saligned.
N3. s/[N]o-= Forward bit/N bit (No-Forward) =C2=A0 Note that No-Forward is used later in= the text.
--001a11c1742057d8ef055fad613a-- From nobody Fri Dec 8 14:32:00 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5777C126CF9; Fri, 8 Dec 2017 14:31:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151277231933.24750.12338629879494753414@ietfa.amsl.com> Date: Fri, 08 Dec 2017 14:31:59 -0800 Archived-At: Subject: [pim] I-D Action: draft-ietf-pim-yang-12.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 22:31:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocols for IP Multicast WG of the IETF. Title : A YANG data model for Protocol-Independent Multicast (PIM) Authors : Xufeng Liu Pete McAllister Anish Peter Mahesh Sivakumar Yisong Liu Fangwei Hu Filename : draft-ietf-pim-yang-12.txt Pages : 70 Date : 2017-12-08 Abstract: This document defines a YANG data model that can be used to configure and manage Protocol Independent Multicast (PIM) devices. The model covers the PIM protocol configuration, operational state, and event notifications data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pim-yang-12 https://datatracker.ietf.org/doc/html/draft-ietf-pim-yang-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pim-yang-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 8 15:06:03 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC912025C; Fri, 8 Dec 2017 15:05:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk CC: stig@venaas.com, pim-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-pim-yang@ietf.org, Stig Venaas , pim@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151277435812.24782.3434819219841612733.idtracker@ietfa.amsl.com> Date: Fri, 08 Dec 2017 15:05:58 -0800 Archived-At: Subject: [pim] Last Call: (A YANG data model for Protocol-Independent Multicast (PIM)) to Proposed Standard X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 23:05:58 -0000 The IESG has received a request from the Protocols for IP Multicast WG (pim) to consider the following document: - 'A YANG data model for Protocol-Independent Multicast (PIM)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-12-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure and manage Protocol Independent Multicast (PIM) devices. The model covers the PIM protocol configuration, operational state, and event notifications data. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-yang/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pim-yang/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (Experimental - IETF stream) rfc3569: An Overview of Source-Specific Multicast (SSM) (Informational - IETF stream) From nobody Sun Dec 10 16:49:21 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A72712426E; Sun, 10 Dec 2017 16:49:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151295335541.21149.6286391138475442264@ietfa.amsl.com> Date: Sun, 10 Dec 2017 16:49:15 -0800 Archived-At: Subject: [pim] I-D Action: draft-ietf-pim-dr-improvement-04.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 00:49:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocols for IP Multicast WG of the IETF. Title : PIM DR Improvement Authors : Zheng(Sandy) Zhang Fangwei Hu BenChong Xu Mankamana Prasad Mishra Filename : draft-ietf-pim-dr-improvement-04.txt Pages : 11 Date : 2017-12-10 Abstract: PIM is widely deployed multicast protocol. PIM protocol is defined in [RFC4601] and [RFC7761]. As deployment for PIM protocol growing day by day, user expect least traffic loss and fast convergence in case of any network failure. This document provides extension to existing defined protocol which would improve stability of PIM protocol with respect to traffic loss and convergence time when the PIM DR is down. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-dr-improvement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-04 https://datatracker.ietf.org/doc/html/draft-ietf-pim-dr-improvement-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pim-dr-improvement-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 11 23:55:56 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF7129405; Mon, 11 Dec 2017 23:55:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-pim-yang.all@ietf.org, ietf@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151306534475.20454.13763239776748812632@ietfa.amsl.com> Date: Mon, 11 Dec 2017 23:55:44 -0800 Archived-At: Subject: [pim] Genart last call review of draft-ietf-pim-yang-12 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:55:45 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pim-yang-?? Reviewer: Roni Even Review Date: 2017-12-11 IETF LC End Date: 2017-12-22 IESG Telechat date: 2018-01-11 Summary: The document is ready for publication as a standard track RFC. I reviewed the document but am not a yang expert. Major issues: Minor issues: Nits/editorial comments: From nobody Tue Dec 12 09:31:36 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF201294DB; Tue, 12 Dec 2017 09:31:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151309989523.8800.7244392021362502763@ietfa.amsl.com> Date: Tue, 12 Dec 2017 09:31:35 -0800 Archived-At: Subject: [pim] IPR Disclosure ZTE Corporation's Statement about IPR related to draft-ietf-pim-dr-improvement X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:31:35 -0000 Dear Zheng Zhang, fangwei hu, BenChong Xu, mankamana prasad mishra: An IPR disclosure that pertains to your Internet-Draft entitled "PIM DR Improvement" (draft-ietf-pim-dr-improvement) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3118/). The title of the IPR disclosure is "ZTE Corporation's Statement about IPR related to draft-ietf-pim-dr-improvement" Thank you IETF Secretariat From nobody Wed Dec 20 09:16:41 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 648071270A3; Wed, 20 Dec 2017 09:16:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151379019536.2735.7462542220207186595@ietfa.amsl.com> Date: Wed, 20 Dec 2017 09:16:35 -0800 Archived-At: Subject: [pim] I-D Action: draft-ietf-pim-source-discovery-bsr-07.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 17:16:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocols for IP Multicast WG of the IETF. Title : PIM flooding mechanism and source discovery Authors : IJsbrand Wijnands Stig Venaas Michael Brig Anders Jonasson Filename : draft-ietf-pim-source-discovery-bsr-07.txt Pages : 16 Date : 2017-12-20 Abstract: PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward multicast packets from new sources. Once last hop routers receive packets from a new source, they may join the Shortest Path Tree for the source for optimal forwarding. This draft defines a new mechanism that provides a way to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM flooding mechanism. This allows last hop routers to learn about new sources without receiving initial data packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pim-source-discovery-bsr-07 https://datatracker.ietf.org/doc/html/draft-ietf-pim-source-discovery-bsr-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pim-source-discovery-bsr-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 20 13:19:29 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7750F128954; Wed, 20 Dec 2017 13:19:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Cc: draft-ietf-pim-yang.all@ietf.org, ietf@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151380475640.2661.756357491589450755@ietfa.amsl.com> Date: Wed, 20 Dec 2017 13:19:16 -0800 Archived-At: Subject: [pim] Opsdir last call review of draft-ietf-pim-yang-12 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:19:16 -0000 Reviewer: Jürgen Schönwälder Review result: Has Issues I have reviewed this document both as ops-dir reviewer and as yang doctor. A more detailed review has been submitted as part of the yang doctor review. Here I am focusing on more general questions from an operational perspective. - There are a number of parameters without defined defaults. Is the idea that every vendor augments in their defaults? Would it not overall be simpler if the PIM WG can find agreement on common defaults? (Vendors can still publish deviations I think.) - I wonder how these YANG modules relate to the PIM MIB modules. Are for example counters the same or different? I think it would be good if the text would discuss relationship of the YANG modules relate to corresponding MIB modules. - There are no example configurations provided, demonstration how, for example, a simple PIM installation would be configured is not present in the document (e.g., as an appendix). From nobody Wed Dec 20 13:22:14 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A02F12751F; Wed, 20 Dec 2017 13:22:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Cc: draft-ietf-pim-yang.all@ietf.org, ietf@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151380493227.2629.15496937140050941194@ietfa.amsl.com> Date: Wed, 20 Dec 2017 13:22:12 -0800 Archived-At: Subject: [pim] Yangdoctors last call review of draft-ietf-pim-yang-12 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:22:12 -0000 Reviewer: Jürgen Schönwälder Review result: Almost Ready * General YANG Review Remarks This document depends on a number of other I-Ds. Is it safe to process this document while the other documents this document depends on are not yet through the process? Who is tracking things and making sure that any changes in other documents that may impact the PIM document are detected and handled appropriately before publication? It is generally good style to write complete sentences in description statements. Some of the description statements are just fractions of a sentence. I think we do not recommend anymore to list WG chairs in the contact statement. It is sometimes not clear why you define groupings that are only used once (and sometimes are likely not reusable since they contain relative paths in must expressions). * Introduction - Is there a reason why you refer to RFC 6020 and to RFC 7950 in sections 1 and 1.2? Why do you need the reference to RFC 6020? - What are 'wider' management interfaces? If you mention NETCONF, why not mention RESTCONF? - s/Protocol-Independent Multicast (PIM) devices /devices supporting Protocol-Independent Multicast (PIM)/ - So which YANG terminology applies, RFC 6020 or RFC 7950? I personally think using YANG 1.1 is pretty safe these days. * Design of Data Model - I did not really understand Section 2.5. It seems you are duplicating objects for different address families but on some systems these duplicate objects must have the same value. If so, where would the must expression go and how does an implementation add such a must expression? How many of such must expressions would there have to be? Did you consider having address family independent objects and optionally (controlled by a feature) per address family objects that overwrite the independent settings? * Module Structure - s/is included/is imported/ - The tree diagrams are rather long. It would likely help readers if the diagram would be split into meaningful units and additional text added to describe the units. Are lists of the form | +--rw ipv4-rp* [ipv4-address] | | +--rw ipv4-address inet:ipv4-address designed for exensibility? Otherwise, this may be collapsed into a simple leaf-list. - Since I am not familiar with details of PIM, I can't comment on the question whether the model makes sense or not. * PIM base Module - YANG modules compile cleanly according to the tracker page. - As said above, consider using YANG 1.1. The ietf-routing module actually uses YANG 1.1 so you will need a YANG 1.1 compiler anyway. - Consider adding reference statements to the feature definitions in case a feature is described in a protocol specification. - The value of timer-value is not really clear, you could have used rt-types:timer-value-seconds16 directly. - Why is graceful-restart/duration using an ad-hoc type for 16-bit seconds and not timer-value? Is it because infinity and not-set does not apply? - Does a bfd/hello-interval of 'infinity' or 'not-set' make sense? - More explicit description of bfd/hello-holdtime? Is a choice really appropriate (hello-holdtime-or-multiplier)? Can I not have both holdtime and multiplier? Perhaps I am just not clear what holdtime does... - Does a bfd/jp-interval of 'infinity' or 'not-set' make sense? - More explicit description of bfd/jp-holdtime? Is a choice really appropriate (jp-holdtime-or-multiplier)? Can I not have both holdtime and multiplier? Perhaps I am just not clear what holdtime does... - Please provide more meaningful descriptions: description "Propagation description"; description "Override interval"; - What is the meaning of the interface augmentation 'oper-status' relative to 'oper-status' defined by ietf-interfaces? Is this just a duplicate with fewer states? Or is this somehow more specific to multicast or PIM packets? In the later case, I think this deserves to the be explained in the description clause. - How do the ip4 and ipv6 addresses relate to ip addresses assigned to an interface in ietf-ip? - What is the meaning of hello-expiration 'not-set'? - What is the meaning of expiration 'not-set'? - Is it useful to return the uptime in seconds (which is changing on every get that is not in the same second) or could it be an option to report the time when something transitioned into the up state (which is not changing)? Well, it could be that we are simply used to uptime like objects. Anyway, the description of up-time should make it clear what exactly is defining the state 'up'. If this says up for 5 seconds, what exactly transitioned into an 'up' state 5 seconds ago? - Is the any restriction for dr-priority or is it a full 32-bit unsigned number space? In some vendor documentation I saw 0..65535 with a default of 1. What do RFCs say? - I am not sure what the precise meaning of the error statistic counters are. What turns an received or sent messages into an error message? The description of grouping statistics-error does not explain this. Also, if I receive a hello and I later decide that this hello must have been an error, is this hello counted twice? And what about messages that could not be parsed because they were malformed, where are those counted? - Why is 'pim' a presence container? - Do comments like 'configuration data nodes' make sense if you include config false nodes in the same branch of the tree? * PIM RP Module - Does the feature bsr-election-state depend on the feature bsr? - Should there be a default bsr-candidate/priority? - Do you need the address/hash-mask-length/priority in bsr-state-attributes in an NMDA implementation? - I _assume_ the bsr-next-bootstrap value has to be interpreted relative to the time the value was obtained. What about making this an absolute timestamp instead? Well, actually I am not sure what the value represents - is it the remaining time interval until the next bootstrap will be sent? - I have no clue what to expect here: leaf group-policy { type string; description "Group policy."; } What can I expect the string to contain? - I am again uncertain how exactly to understand the value of rp-candidate-next-advertisement, see similar questions above. - What are the policy values that can go into this: leaf policy-name { type string; description "Static RP policy."; } Is the string just an arbitrary name or does it mean something? - How is this supposed to be used? leaf policy { type string; description "ACL (Access Control List) policy used to filter group addresses."; } What is the meaning of foo? * PIM SM Module - What is the meaning of a policy-name value? leaf policy-name { if-feature spt-switch-policy; type string; description "Switch policy."; } - What is the meaning of a range-policy value? leaf range-policy { type string; description "Policy used to define SSM address range."; } * PIM DM Module - I wonder, would you need an identity for dense mode? * PIM BIDIR Module - Remove /* * Typedefs */ - What is the meaning of offer-interval or backoff-interval 'not-set'? * Implementation Status It seems the trac page pointed to was used to collect information about what proprietary implementation support, i.e., it does not document to what extend the models defined in this document have been implemented. There are some notable differences. For example, it seems most counters implemented are 32-bit while most counters in the YANG models are 64-bit. How chatty is PIM, are 64-bit counters really needed and are implementors willing to move to 64-bit counters? * Security Considerations I think this needs to include a bit more details. See https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines for the latest template that YANG module authors are expected to use. From nobody Wed Dec 20 13:52:25 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 659FA1200C5; Wed, 20 Dec 2017 13:52:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk CC: pim-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-pim-source-discovery-bsr@ietf.org, mmcbride7@gmail.com, Mike McBride , pim@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151380674439.2754.12050058925477081397.idtracker@ietfa.amsl.com> Date: Wed, 20 Dec 2017 13:52:24 -0800 Archived-At: Subject: [pim] Last Call: (PIM flooding mechanism and source discovery) to Experimental RFC X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:52:24 -0000 The IESG has received a request from the Protocols for IP Multicast WG (pim) to consider the following document: - 'PIM flooding mechanism and source discovery' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward multicast packets from new sources. Once last hop routers receive packets from a new source, they may join the Shortest Path Tree for the source for optimal forwarding. This draft defines a new mechanism that provides a way to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM flooding mechanism. This allows last hop routers to learn about new sources without receiving initial data packets. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1647/ From nobody Wed Dec 20 21:21:46 2017 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43187127444; Wed, 20 Dec 2017 21:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVeL6sXqKWNE; Wed, 20 Dec 2017 21:21:40 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1361201FA; Wed, 20 Dec 2017 21:21:39 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AA66458C4B7; Thu, 21 Dec 2017 06:21:35 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 89210B0D4FD; Thu, 21 Dec 2017 06:21:35 +0100 (CET) Date: Thu, 21 Dec 2017 06:21:35 +0100 From: Toerless Eckert To: ietf@ietf.org Cc: IETF-Announce , draft-ietf-pim-source-discovery-bsr@ietf.org, Mike McBride , pim-chairs@ietf.org, pim@ietf.org Message-ID: <20171221052135.GA30645@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [pim] Last Call: (PIM flooding mechanism and source discovery) to Experimental RFC X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 05:21:43 -0000 This is a very good and in general very well written draft (take the two nits described below). I hope we will see more implementation of it so that it can evolve from experimental to standards track. Two suggestions: a) Textual: I would suggest changing the title from PIM flooding mechanism and source discovery to PIM flooding mechanism (PFM) and PIM source discovery (GSH) This is only to make it easier to search for the key introduced protocol TLAs in the RFC index r search engines (PFM & GSH). Especially because the TLA for PIM source discovery defined in this document is not obvious: not PSD but GSH. There is also the old? term PFM-SA used in terminology/section-2, which i guess should rather be PFM-GSH (e.g.: PFM-SA is not used in rest of doc). b) Context: It would IMHO be helpful for candidate adopters and implementors if there was a few more high level explanations re. the relationship of PSM-GSH to other multicast options and what i think the strategic goal or benefits are (which is why the WG was interested in working on it): Technically, PFM-GSH is similar to PIM-DM with its State-Refresh (SR) signaling, with the following differences: - PSM-GSH does not suffer from unnecessary initially flooded traffic (before SR can be effective) - as seen from prototype tests (section 2). - PSM-GSH provides the ease of deployment and operations of PIM-DM (vs. PIM-SM) but the traffic efficiency of PIM-SM. In return it can not provide the forwarding of initial/bursty packets. - PSM-GSH does not require implementing & supporting the vastly different protocol and forwarding machinery of PIM-DM vs. the current standards basis in products of PIM-SSM/SM: Architecturally, PFM-GSH allows to provide lightweight IP Multicast ASM (Any Source Multicast - RFC1112) on top of an underlying basis of SSM/PIM-SM and forego all the complexity of full PIM-SM (RP forwarding and control plane): - In the forwarding plane, only PIM-SSM ( (S,G) forwarding) is required plus some platform mechanism on FHR to discover directly connected active SG. - In the control plane, only PIM-SSM plus PFM-GSH is required. In summary: PSM-GSH could lead to further simplify IP multicast operations in networks: Eliminate the need for PIM-DM and full PIM-SM and rely on PIM-SSM and optional PSM-GSH in support of applications that can not provide their own source discovery (and therefore are able to leverage SSM/PIM-SM directly). Cheers Toerless On Wed, Dec 20, 2017 at 01:52:24PM -0800, The IESG wrote: > > The IESG has received a request from the Protocols for IP Multicast WG (pim) > to consider the following document: - 'PIM flooding mechanism and source > discovery' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-01-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward > multicast packets from new sources. Once last hop routers receive > packets from a new source, they may join the Shortest Path Tree for > the source for optimal forwarding. This draft defines a new > mechanism that provides a way to support PIM Sparse Mode (SM) without > the need for PIM registers, RPs or shared trees. Multicast source > information is flooded throughout the multicast domain using a new > generic PIM flooding mechanism. This allows last hop routers to > learn about new sources without receiving initial data packets. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-pim-source-discovery-bsr/ballot/ > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/1647/ > > > > -- --- tte@cs.fau.de From nobody Thu Dec 21 12:57:11 2017 Return-Path: X-Original-To: pim@ietf.org Delivered-To: pim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C6312895E; Thu, 21 Dec 2017 12:57:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: stig@venaas.com, pim-chairs@ietf.org, pim@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151388983090.12940.3636891512244947920.idtracker@ietfa.amsl.com> Date: Thu, 21 Dec 2017 12:57:10 -0800 Archived-At: Subject: [pim] pim - New Meeting Session Request for IETF 101 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 20:57:11 -0000 A new meeting session request has just been submitted by Stig Venaas, a Chair of the pim working group. --------------------------------------------------------- Working Group Name: Protocols for IP Multicast Area Name: Routing Area Session Requester: Stig Venaas Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: mboned bess Second Priority: rtgwg bier i2rs rtgarea netconf netmod Third Priority: spring softwire idr nvo3 homenet lisp ospf People who must be present: Mike McBride Stig Venaas Alvaro Retana Resources Requested: Special Requests: We would be happy to share our meeting slot with mboned as usual. --------------------------------------------------------- From nobody Sat Dec 30 07:12:41 2017 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39770124205; Sat, 30 Dec 2017 07:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmtRnZmnP8cR; Sat, 30 Dec 2017 07:12:39 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3C3120713; Sat, 30 Dec 2017 07:12:38 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBUFCY9R018711; Sat, 30 Dec 2017 15:12:34 GMT Received: from 950129200 ([193.57.120.171]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBUFCW9l018701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Dec 2017 15:12:33 GMT Reply-To: From: "Adrian Farrel" To: Cc: , , Date: Sat, 30 Dec 2017 15:12:36 -0000 Message-ID: <010901d38180$a0f38ff0$e2daafd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOBgEavRPJMMLo6TiuYFJT/uCHC+w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23564.000 X-TM-AS-Result: No--9.005-10.0-31-10 X-imss-scan-details: No--9.005-10.0-31-10 X-TMASE-MatchedRID: eeUnDllZ99htcr/uuDMv3m7hbmASKcrpQPCWRE0Lo8LIvQIyugvKdVjt prj9/vncRTpdHYygurQZwn7DIQtGC+4dcT3ZaToc+L2GsArAgtofXzVgO0hVqrrfxlRjqBJ3FhM gncTYqySEffBdqJ9bt9Rb3Q9vGGb1vn+AFle5KGKvdf2B19ItZZFLUnnvueyBc8FZmOUzKzbaQG WiWaQYJbIA3x+6SpckQwwy/cd0phjjNn0Okk5VX0Zakoam9+aeQPCPzycuBFNZQ1dCoB0lh0rnK ix7t5mTvZLi5RQy1neE8bKqMVp+ntXQ2R27CZyz1N5tiqLHMguEQiKo28GuY1mmz7LVVfOpCWJo blTvUKL6HhZWpEMzZBJ9TPcQEwRYkiGg8AH+HIiTd7CJ8bYw01PgO2JKQydYjU56jjASCeHAeq5 888pQ6xe8J2RweKCoX4EEF3IhqZp1lZiYcaoZiMWUKBjERoYTERzrQ87nh6rVl0v7E9KhhqtdBZ swv8LDTc03k8m3BJHHZ8+jv0CzYPAvve5vrq0sffXtKyM+c+s5vvch9MIrZCJCNKaWd/XP+5i5n 31cQPEoAnd0YbrN34rmmltxTGj+D0VXqQ1iI8fi3aa5wOREES5RABfuDLQM0KaJBUk7woBL5V27 T2utfEyRraHfqQCMTIwiaSLSwPi0/JWJqIoqppmug812qIbzs+SyIdviDnwWoS+vMj3A25VDZsT 0rYWCu7bTkgebPnOnqW3VSGf5d01+zyfzlN7y/sToY2qzpx7dB/CxWTRRu25FeHtsUoHusE5hry JgQ0K4HbZc57xyxN26p7lrRwNamPcGcL81GZzrpcchznD6Bw== Archived-At: Subject: [pim] RtgDir review: draft-ietf-pim-yang-12 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 15:12:41 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Adrian Document: draft-ietf-pim-yang-12.txt Reviewer: Adrian Farrel Review Date: 2017-12-30 IETF LC End Date: date-if-known 2017-12-22 Intended Status: Standards Track ==Summary:== Sorry that this review comes after last call, but the request only reached me on 2017-12-27 I have some minor concerns about this document that I think should be resolved before publication. ==Comments:== This document supplies a collection of YANG modules to configure and monitor a PIM implementation. The separate modules are intended to make it possible to operate an implementation that uses only a subset of the features of the protocol. This is good work. A relatively easy read despite combining YANG and PIM in one document. I would note that it has been a long time since I last looked at PIM, and I was never an expert. I am also not a YANG expert. Ultimately the test of this sort of work is to know that it has been implemented and successfully used to control/operate PIM devices. The information at https://trac.ietf.org/trac/pim/wiki/yang is a good start although does not appear to show wide support for all the objects in this model. ==Major Issues:== I expected to see defaults defined in the modules. 2.4 says... > Where fields are not genuinely essential to protocol operation, they > are marked as optional. Some fields will be essential but have a > default specified, so they need not be explicitly configured. ...which is a strong hint that there should be some defaults, but a search for the "default2 statement turns up none. Now, if I look at 7761 (which, surprisingly, I did) I see statements like... > The DR Priority option allows a network administrator to give > preference to a particular router in the DR election process by > giving it a numerically larger DR Priority. The DR Priority option > SHOULD be included in every Hello message, even if no DR Priority is > explicitly configured on that interface. This is necessary because > priority-based DR election is only enabled when all neighbors on an > interface advertise that they are capable of using the DR Priority > option. The default priority is 1. ...which is a stronger hint that there should be a least one default available for the configuration of the local DR priority. ==Minor Issues:== The introduction could use a citation of RFC 7761. --- typedef pim-mode has an enum called "other". AFAICS there is no mention of other modes anywhere else in the document. It might be good to flesh the description out a little and/or add text to the overview (maybe 2.4?). --- DR priority is optional on Hello messages. 7761 ss 4.3.2 notes that "the following information about the sending neighbor is recorded" and lists (as well as dr_priority) dr_priority_present which it describes as "A flag indicating if the DR Priority field was present in the Hello message." I can't see how that piece of information is accessed in this model. ==Nits:== The Document Shepherd write-up will need to explain why >5 front page authors --- The document title needs correct capitalisation. --- Please choose and consistently hyphenate "Protocol Independent Multicast" --- Section 1 Your wording... > YANG [RFC6020] [RFC7950] is a data definition language ...is unusual. Normally say it is a "data modeling language". That is how 7950 describes YANG. --- Please fix capitalisation in section headings --- 3.4 and 3.5 you have "This module will cover..." You should probably use "This module covers..."