Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

From: Greg Shepherd <[email-masked]>
Date: Sat, 21 Sep 2019 14:00:18 -0700

The doc has been rev'd with the proposed changes. Let's restart a short
WGLC - week. Please read and respond to this thread by Oct 4, 2019

Thanks,
Greg

 On Thu, Apr 18, 2019 at 1:40 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Inline
>>
>> Regards
>>
>> Hooman
>>
>> -----Original Message-----
>> From: Stig Venaas <[email-masked]>
>> Sent: Thursday, April 18, 2019 4:29 PM
>> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
>> Cc: Ijsbrand Wijnands <[email-masked]>; [email-masked]; Jeffrey
>> (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda <[email-masked]>;
>> Mankamana Mishra (mankamis) <[email-masked]>
>> Subject: Re: [Bier] WG LC on
>> https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>>
>> Hi
>>
>> Sorry for delay.
>>
>> HB> thanks for the comments!
>>
>> This looks good, except that in the diagram it says "Type = 6"
>>
>> HB> agreed thank you!
>>
>> but below it says TBD. It should say TBD in the diagram as well.
>> Just editorial, but I think it should say IPv4, IPv6, "PIM packet" and
>> maybe BFR-ID?
>>
>> HB> ok agreed, this is really base on the bier prefix so I will change
>> the text.
>>
>> Stig
>>
>> On Mon, Apr 15, 2019 at 8:15 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
>> [email-masked]> wrote:
>> >
>> > Hi Stig
>> >
>> > Could you please confirm if you are ok with below or you have any other
>> input/comments... That way I can post a final version.
>> >
>> > Much appreciated!
>> >
>> > Regards
>> >
>> > Hooman
>> >
>> > -----Original Message-----
>> > From: Bidgoli, Hooman (Nokia - CA/Ottawa)
>> > Sent: Wednesday, April 10, 2019 3:07 PM
>> > To: Stig Venaas <[email-masked]>; Ijsbrand Wijnands <[email-masked]>
>> > Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda
>> > <[email-masked]>; Mankamana Mishra (mankamis) <[email-masked]>
>> > Subject: RE: [Bier] WG LC on
>> > https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>> >
>> > Hi Stig et al
>> >
>> > Thanks for comments
>> >
>> > Just to close the loop I will add the following, please let me know if
>> you are good with it...
>> >
>> >
>> >     0                   1                   2                   3
>> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >       |F|E|  Type=tbd  |    Length     |  Addr Family  |  BIER info
>> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>> >
>> >    F bit:   The Transitive bit.  Specifies whether this attribute is
>> >       transitive or non-transitive.  MUST be set to zero.  This
>> >       attribute is ALWAYS non-transitive.
>> >
>> >    E bit:   End-of-Attributes bit.  Specifies whether this attribute is
>> >       the last.  Set to zero if there are more attributes.  Set to 1 if
>> >       this is the last attribute.
>> >
>> >    Type:   TBD assign by IANA
>> >
>> >    Length:   The length in octets of the attribute value.  MUST be set
>> >       to the length in octets of the BIER info +1 octet
>> >       to account for the Address Family field.
>> >        For Ipv4 AF Length = 7+1
>> >        For Ipv6 AF Length = 19+1
>> >
>> >    Addr Family:   The PIM Address Family of the receiver Pim packet as
>> defined
>> >       in [RFC7761].
>> >
>> >    BIER Info: IBBR Prefix, SD, bfr-id
>> >
>> > Regards
>> >
>> > Hooman
>> >
>> > -----Original Message-----
>> > From: Stig Venaas <[email-masked]>
>> > Sent: Tuesday, March 26, 2019 9:45 AM
>> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
>> > Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; BIER WG
>> > <[email-masked]>; Antoni Przygienda <[email-masked]>; Mankamana Mishra
>> > (mankamis) <[email-masked]>
>> > Subject: Re: [Bier] WG LC on
>> > https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>> >
>> > Hi
>> >
>> > I have a comment on the attribute text in the draft.
>> >
>> > It says:
>> >    Attr_type=TBD (BIER IBBR info IPv4): lenght=6 ; value=IBBR Prefix
>> >    (ipv4), SD, bfr-id
>> >
>> >    Attr_type=TBD (BIER IBBR info IPv6): lenght=19 ; value=IBBR Prefix
>> >    (ipv6), SD, bfr-id
>> >
>> > Most importantly, for IPv4, the length should be 7! I also think
>> > though that it would be useful to have a diagram. Also if you look at
>> > other attributes defined
>> > https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#p
>> > im-parameters-2 you will see that the same option is used for both
>> > IPv4 and IPv6. I would suggest doing a diagram and using AF similar to
>> RFC 8059 section 5.1.
>> >
>> > Regards,
>> > Stig
>> >
>> > On Fri, Dec 7, 2018 at 7:53 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
>> [email-masked]> wrote:
>> > >
>> > > Jeffery/Stig/Eric
>> > >
>> > > Thanks again for your feedbacks...
>> > >
>> > > Bringing the working group into the loop
>> > >
>> > > RFC 5384 was proposed to be used to relay the IBBR info to EBBR
>> > >
>> > > Two new Attr types was proposed for identifying IBBR IPv4 and IPv6
>> address family.
>> > >
>> > >    0                   1                   2                   3
>> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    | Addr Family   | Encoding Type | Rsrvd   |S|W|R|  Mask Len     |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |               Source Address
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
>> > >    |F|E| Attr_Type | Length        | Value
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
>> > >
>> > > Encoding type = 1
>> > > F = 0
>> > > Attr_type= 7 (New IANA BIER IBBR info IPv4) Vlaue = IBBR Prefix, SD,
>> > > bfr-id Attr_type= 8 (New IANA BIER IBBR info IPv6) Vlaue = IBBR
>> > > Prefix, SD, bfr-id
>> > >
>> > > IBBR Prefix: this is IPv4 or IPv6 BFR-Prefix of the IBBR for the
>> > > specific subdomain as described in [RFC8279]
>> > > SD: This is a 8-bit field that encodes the Sub-Domain as described in
>> [RFC8279].
>> > > BFR-ID: this is a 16-bit field which identifies the BFR uniquely
>> > > with in the subdomain as described in [RFC8279]
>> > >
>> > >
>> > >
>> > > Regards
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: BIER <[email-masked]> On Behalf Of Eric Rosen
>> > > Sent: Monday, November 19, 2018 10:32 AM
>> > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>;
>> > > Jeffrey (Zhaohui) Zhang <[email-masked]>
>> > > Cc: Stig Venaas <[email-masked]>; BIER WG <[email-masked]>; Antoni
>> > > Przygienda <[email-masked]>
>> > > Subject: Re: [Bier] WG LC on
>> > > https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>> > >
>> > > On 11/18/2018 4:53 PM, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
>> > > > Jeffery/Stig
>> > > >
>> > > > Going back to the comments in the IETF for an optional TLV to
>> identify the IBBR in the PIM join.
>> > > >
>> > > > 1.    Jeffrey forwarded RFC 5384, I am not sure how the TLVs in
>> this RFC will help to identify the IBBR in the PIM signaling packet?
>> > >
>> > > RFC 5384 is about how to add attributes to PIM Joins.  I think the
>> suggestion is that a new Join attribute (identifying the IBBR) needs to be
>> defined.
>> > >
>> > > > 2.    Thinking more about this, If the implementation on EBBR
>> dictates that the PIM message needs to have an optional TLV that identifies
>> the IBBR, why can't the EBBR add that TLV to the PIM signaling packet
>> before it sends it to the PIM task. All the info are available in the BIER
>> header and before the signaling packet is send to the PIM task on EBBR the
>> EBBR can add this information as an optional TLV. I
>> > >
>> > > Stig is obviously concerned about an implementation in which (a) the
>> ability to pass information about the packet from hardware to software is
>> limited, and (b) the ability to modify the packet before passing it to the
>> control plane processor is minimal or non-existent.  And if these abilities
>> exist, it might involve difficult-to-incorporate microcode changes.  These
>> issues aren't that mysterious.
>> > >
>> > >
>> > > _______________________________________________
>> > > BIER mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/bier
>>
>

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Sun, 22 Sep 2019 11:34:30 +0000

Support.
The document is ready.

Thanks.
Jorge

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Saturday, September 21, 2019 at 11:00 PM
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>, BIER WG <[email-masked]>
Cc: Stig Venaas <[email-masked]>, "Mankamana Mishra (mankamis)" <[email-masked]>, Ijsbrand Wijnands <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Antoni Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

The doc has been rev'd with the proposed changes. Let's restart a short WGLC - week. Please read and respond to this thread by Oct 4, 2019

Thanks,
Greg

 On Thu, Apr 18, 2019 at 1:40 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Inline

Regards

Hooman

-----Original Message-----
From: Stig Venaas <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 18, 2019 4:29 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Ijsbrand Wijnands <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra (mankamis) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Hi

Sorry for delay.

HB> agreed thank you!

but below it says TBD. It should say TBD in the diagram as well.
Just editorial, but I think it should say IPv4, IPv6, "PIM packet" and maybe BFR-ID?

HB> ok agreed, this is really base on the bier prefix so I will change the text.

Stig

On Mon, Apr 15, 2019 at 8:15 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Stig
>
> Could you please confirm if you are ok with below or you have any other input/comments... That way I can post a final version.
>
> Much appreciated!
>
> Regards
>
> Hooman
>
> To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; Ijsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
> Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Antoni Przygienda
> <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra (mankamis) <[email-masked]<mailto:[email-masked]>>
> Just to close the loop I will add the following, please let me know if you are good with it...
>
>
>     0                   1                   2                   3
>    Addr Family:   The PIM Address Family of the receiver Pim packet as defined
>       in [RFC7761].
>
> From: Stig Venaas <[email-masked]<mailto:[email-masked]>>
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
> Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; BIER WG
> <[email-masked]<mailto:[email-masked]>>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra
> (mankamis) <[email-masked]<mailto:[email-masked]>>
> IPv4 and IPv6. I would suggest doing a diagram and using AF similar to RFC 8059 section 5.1.
>
> Regards,
> Stig
>
> On Fri, Dec 7, 2018 at 7:53 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Jeffery/Stig/Eric
> >
> > Two new Attr types was proposed for identifying IBBR IPv4 and IPv6 address family.
> >
> >    0                   1                   2                   3
> > SD: This is a 8-bit field that encodes the Sub-Domain as described in [RFC8279].
> > From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rosen
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>;
> > Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
> > Cc: Stig Venaas <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Antoni
> > Przygienda <[email-masked]<mailto:[email-masked]>>
> > > Going back to the comments in the IETF for an optional TLV to identify the IBBR in the PIM join.
> > >
> > > 1.    Jeffrey forwarded RFC 5384, I am not sure how the TLVs in this RFC will help to identify the IBBR in the PIM signaling packet?
> >
> > RFC 5384 is about how to add attributes to PIM Joins.  I think the suggestion is that a new Join attribute (identifying the IBBR) needs to be defined.
> >
> > > 2.    Thinking more about this, If the implementation on EBBR dictates that the PIM message needs to have an optional TLV that identifies the IBBR, why can't the EBBR add that TLV to the PIM signaling packet before it sends it to the PIM task. All the info are available in the BIER header and before the signaling packet is send to the PIM task on EBBR the EBBR can add this information as an optional TLV. I
> >
> > Stig is obviously concerned about an implementation in which (a) the ability to pass information about the packet from hardware to software is limited, and (b) the ability to modify the packet before passing it to the control plane processor is minimal or non-existent.  And if these abilities exist, it might involve difficult-to-incorporate microcode changes..  These issues aren't that mysterious.
> >
> >
> > [email-masked]<mailto:[email-masked]>

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 24 Sep 2019 15:35:53 +0000

Support as co-author . Document is ready to progress .

Sent from my iPhone

On Sep 21, 2019, at 14:00, Greg Shepherd <[email-masked]> wrote:

Thanks,
Greg

Regards

Hooman

-----Original Message-----
From: Stig Venaas <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 18, 2019 4:29 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Ijsbrand Wijnands <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra (mankamis) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Hi

Sorry for delay.

HB> agreed thank you!

Stig

On Mon, Apr 15, 2019 at 8:15 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
> > Stig is obviously concerned about an implementation in which (a) the ability to pass information about the packet from hardware to software is limited, and (b) the ability to modify the packet before passing it to the control plane processor is minimal or non-existent.  And if these abilities exist, it might involve difficult-to-incorporate microcode changes.  These issues aren't that mysterious.
> >
> >

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Sep 2019 10:51:02 -0700

Hi

This is good work and I generally support the document. There are
however some issues that need to be addressed. I also think it
would be good to get this reviewed in the pim WG, perhaps you
can ask for reviews on the pim list.

I mostly have editorial comments that are easy to address. But at
a high level I think some more text about pim is needed.

PIM relies on hello messages to know what capabilities a router
has, e.g. whether it support Join attributes, whether it support
BIDIR etc. I think you need to point out what capabilities are
assumed to be present. Obviously it is assumed that Join
attributes are supported. It may also be good to point out that
there is no J/P suppression as the J/P is only sent to the target,
and not to other routers. Also point out that only J/P messages
are used, and that there is no assert processing.

Below are the editorial comments. Please also check the "nits"
tool. It complains about missing references, and it cannot find
the "Authors' Addresses" section. The heading is missing.

Also Section 7 must be updated. There is an IANA action, but
it says there are none!

The abstract is rather long. Suggest removing some of the text that
explains the general operation of BIER.

Some of the references might need some work. In section 2 it
says "RFC 2119 [RFC2119]". Should it be just "[RFC2119]"? Also
the reference is missing.  In 2.1 it says "[I-D. rfc8279]" which
also needs to be fixed. Most of the other references look fine.
In 3.1 there seems to be a reference to 8279 without brackets though.

In 2.1, BFR definition. Missing space after ".".

BFIR definition: It says "insert the BM into the packet", but I think it
might be better to say that it performs BIER encapsulation. The term BM
is not defined. It says "plain" instead of "plane".

BFER defintion: Do we have to say that BFER is a BFR? In that case, we
should also say that BFIR is a BFR. It says "plain" instead of "plane".

IBBR and EBBR, might it be good to include "signaling" in the name, like
Ingress Signaling BIER Router and Egress Signaling BIER Router? I want it
to be very clear that ingress and egress are not related to data.

In "Figure 1" I think "bfir" and "bfer" should be upper case.

In 3.1:
"weather" should be "whether".
"located on" should probably be "located in".

In 3.1 there is this paragraph that I think need some changes.

   After discovering the EBBR and its BFR-ID (flooded via IGP BIER
   extension), the IBBR will construct a PIM Join Attribute encoded as

It says that BFR-ID is flooded via IGP BIER extension. That isn't
necessarily true, do we need to explain how the BFR-ID is discovered?

   TLVs into the Source Address field of the PIM Join Message as per

Isn't it just one TLV? I think you can skip saying that it is a TLV
in the source address field. Just say that it includes a new PIM
Join Attribute in the Join/Prune message. Also note that we should
really say Join/Prune, not just Join.

   [RFC5384] and include it in PIM signaling message. Two new "BIER

I think it is better to be clear and say PIM Join/Prune message.

   IBBR" attributes are define and explained in upcoming section. The
s/define/defined

   PIM Join Attribute is used on EBBR to obtain necessary bier
s/bier/BIER
   information to build its multicast states. In addition the IBBR will
   change the PIM signaling packet source IP address to its BIER prefix
   address (standard PIM procedure). It will also keep the destination
   address as the well known multicast IP address. It then will
   construct the BIER header. The signaling packet, in this case the PIM
   join/prune packet, is encapsulated in the BIER header and transported
   through BIER domain to EBBR.

The language at the end here makes it sound like the PIM J/P is being
forwarded and that the J/P is being modified. But J/P messages are sent
hop-by-hop. Each router originates a new J/P. For instance, a router
may receive a J/P for multiple sources. These sources may have different
RPF neighbors on the receiving router and hence be split into separate
join messages. This could happen on the IBBR as well.

The lasts paragraph in section 3 says:
   The IBBR will track all the PIM interfaces on the attached PIM domain
   which are interested in a certain (S,G). It creates multicast states
   for arriving (S,G)s from PIM domain, with incoming interface as BIER
   "tunnel" interface and outgoing interface as the PIM domain
   interface(s) on which PIM Join(s) were received on.

The IBBR is a PIM router and what you are describing is standard PIM
behavior, so I think this is a bit redundant. It might be goot to
stress that OIFs are adding according to standard PIM behavior. The only
special here is the RPF interface.

Section 3.1.4:
In heading Pim/PIM
bier/BIER

It says "PIM Join Attribute [RFC5384] is used." I think it might be good
to say that "a new PIM Join Attribute is used". And then also this
sentence "The PIM Join Attribute format is as follow:" should perhaps be
The new PIM Join Attribute format is defined as follows:".

s/Ipv4/IPv4
s/Ipv6/IPv6

In the format I think it might be good to not just show "BIER info", but
show the formatting of prefix, SD and BFR-ID explicitly. Also, it should
state clearly that these are the prefix, SD and BFR-id of the IBBR.

In 3.1.4.1 why not say PIM Join/Prune packet instead of PIM signaling?

In 3.3.:
   After receiving the BIER packet and determining this packet is a
   signaling packet, EBBR will remove the BIER header from PIM packet.
   The Received PIM join/prune Signaling packet is processed as if it
   were received from neighbors on a virtual interface, (i.e. as if the
   pim adjacency was presents, regardless of the fact there is no
   adjacency)
Wouldn't the router remove the BIER header simply because the BFR-id
in the BIER header matches its own BFR-id? There are some grammar issues
and a missing period in this paragraph.

In this paragraph:
   With same token the EBBR creates a multicast state with incoming
   interface as same interface that PIM join packet was forwarded and
   outgoing interfaces of BIER tunnel to BFER identified with BFIR-id
   and its corresponding Sub-Domain obtained from the BIER header or via
   PIM Join Attributes added to the PIM signaling packet by the IBBR.

I'm not sure what "With same token" means here. Also, it not should say
that PIM join packet was forwarded. I would say that state is created
according to the PIM specification, and just describe the BIER OIF state.
The specific OIF state may be implementation specific though. Perhaps this
is sufficiently described in the paragraph that comes right after? It is
also well described in 4.1.

In section 5: s/LEAFs/leaves? Should it be EBBRs?

In section 6:
s/vrf/VRF
"it is determine" should be "it is determined".
Replace "PIM signaling message" with "PIM Join/Prune message"?

Section 8:
The 4601 reference should be to RFC 7761.

Appendix A:
The header seems to not be formatted correctly.
"This section" should be "This appendix"?

In A.1: "is consist" should be "consists".

In Figure 2: s/bier/BIER
Also in the text in A.2.2.

IN A.3.1
s/Bier/BIER
s/bier/BIER
s/tlv/TLV

Stig

---

From: Nabeel Cocker <[email-masked]>
Date: Tue, 24 Sep 2019 13:56:04 -0400

Fully support

Thanks
Nabeel

On Tue, Sep 24, 2019 at 11:37 AM Mankamana Mishra (mankamis) <
[email-masked]> wrote:

>>> > Could you please confirm if you are ok with below or you have any
>>> other input/comments... That way I can post a final version.
>>> >
>>> > Much appreciated!
>>> >
>>> > Regards
>>> >
>>> > Hooman
>>> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 24 Sep 2019 20:20:58 +0000

As a co-author I support progressing the work. Obviously we'll look into the comments from Stig below and address them.

Thanks!
Jeffrey

-----Original Message-----
From: Stig Venaas <[email-masked]> 
Sent: Tuesday, September 24, 2019 1:51 PM
To: Mankamana Mishra (mankamis) <[email-masked]>
Cc: [email-masked]; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; BIER WG <[email-masked]>; Ijsbrand Wijnands <[email-masked]>; [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda <[email-masked]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Hi

This is good work and I generally support the document. There are however some issues that need to be addressed. I also think it would be good to get this reviewed in the pim WG, perhaps you can ask for reviews on the pim list.

I mostly have editorial comments that are easy to address. But at a high level I think some more text about pim is needed.

PIM relies on hello messages to know what capabilities a router has, e.g. whether it support Join attributes, whether it support BIDIR etc. I think you need to point out what capabilities are assumed to be present. Obviously it is assumed that Join attributes are supported. It may also be good to point out that there is no J/P suppression as the J/P is only sent to the target, and not to other routers. Also point out that only J/P messages are used, and that there is no assert processing.

Below are the editorial comments. Please also check the "nits"
tool. It complains about missing references, and it cannot find the "Authors' Addresses" section. The heading is missing.

Also Section 7 must be updated. There is an IANA action, but it says there are none!

The abstract is rather long. Suggest removing some of the text that explains the general operation of BIER.

Some of the references might need some work. In section 2 it says "RFC 2119 [RFC2119]". Should it be just "[RFC2119]"? Also the reference is missing.  In 2.1 it says "[I-D. rfc8279]" which also needs to be fixed. Most of the other references look fine.
In 3.1 there seems to be a reference to 8279 without brackets though.

BFIR definition: It says "insert the BM into the packet", but I think it might be better to say that it performs BIER encapsulation. The term BM is not defined. It says "plain" instead of "plane".

BFER defintion: Do we have to say that BFER is a BFR? In that case, we should also say that BFIR is a BFR. It says "plain" instead of "plane".

IBBR and EBBR, might it be good to include "signaling" in the name, like Ingress Signaling BIER Router and Egress Signaling BIER Router? I want it to be very clear that ingress and egress are not related to data.

In 3.1:

It says that BFR-ID is flooded via IGP BIER extension. That isn't necessarily true, do we need to explain how the BFR-ID is discovered?

Isn't it just one TLV? I think you can skip saying that it is a TLV in the source address field. Just say that it includes a new PIM Join Attribute in the Join/Prune message. Also note that we should really say Join/Prune, not just Join.

   IBBR" attributes are define and explained in upcoming section. The s/define/defined

   PIM Join Attribute is used on EBBR to obtain necessary bier s/bier/BIER

The language at the end here makes it sound like the PIM J/P is being forwarded and that the J/P is being modified. But J/P messages are sent hop-by-hop. Each router originates a new J/P. For instance, a router may receive a J/P for multiple sources. These sources may have different RPF neighbors on the receiving router and hence be split into separate join messages. This could happen on the IBBR as well.

The IBBR is a PIM router and what you are describing is standard PIM behavior, so I think this is a bit redundant. It might be goot to stress that OIFs are adding according to standard PIM behavior. The only special here is the RPF interface.

Section 3.1.4:
In heading Pim/PIM
bier/BIER

It says "PIM Join Attribute [RFC5384] is used." I think it might be good to say that "a new PIM Join Attribute is used". And then also this sentence "The PIM Join Attribute format is as follow:" should perhaps be The new PIM Join Attribute format is defined as follows:".

s/Ipv4/IPv4
s/Ipv6/IPv6

In the format I think it might be good to not just show "BIER info", but show the formatting of prefix, SD and BFR-ID explicitly. Also, it should state clearly that these are the prefix, SD and BFR-id of the IBBR.

In 3.3.:
Wouldn't the router remove the BIER header simply because the BFR-id in the BIER header matches its own BFR-id? There are some grammar issues and a missing period in this paragraph.

In this paragraph:

I'm not sure what "With same token" means here. Also, it not should say that PIM join packet was forwarded. I would say that state is created according to the PIM specification, and just describe the BIER OIF state.
The specific OIF state may be implementation specific though. Perhaps this is sufficiently described in the paragraph that comes right after? It is also well described in 4.1.

In section 6:
s/vrf/VRF

Section 8:

Appendix A:

In Figure 2: s/bier/BIER

IN A.3.1
s/Bier/BIER
s/bier/BIER
s/tlv/TLV

Stig