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) <
hooman.bidgoli@nokia.com> wrote:

> Inline
>>
>> Regards
>>
>> Hooman
>>
>> -----Original Message-----
>> From: Stig Venaas <stig@venaas.com>
>> Sent: Thursday, April 18, 2019 4:29 PM
>> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
>> Cc: Ijsbrand Wijnands <ice@cisco.com>; bier-chairs@ietf.org; Jeffrey
>> (Zhaohui) Zhang <zzhang@juniper.net>; Antoni Przygienda <prz@juniper.net>;
>> Mankamana Mishra (mankamis) <mankamis@cisco.com>
>> 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) <
>> hooman.bidgoli@nokia.com> 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 <stig@venaas.com>; Ijsbrand Wijnands <ice@cisco.com>
>> > Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Antoni Przygienda
>> > <prz@juniper.net>; Mankamana Mishra (mankamis) <mankamis@cisco.com>
>> > 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 <stig@venaas.com>
>> > Sent: Tuesday, March 26, 2019 9:45 AM
>> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
>> > Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; BIER WG
>> > <bier@ietf.org>; Antoni Przygienda <prz@juniper.net>; Mankamana Mishra
>> > (mankamis) <mankamis@cisco.com>
>> > 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) <
>> hooman.bidgoli@nokia.com> 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 <bier-bounces@ietf.org> On Behalf Of Eric Rosen
>> > > Sent: Monday, November 19, 2018 10:32 AM
>> > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>;
>> > > Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
>> > > Cc: Stig Venaas <stig@venaas.com>; BIER WG <bier@ietf.org>; Antoni
>> > > Przygienda <prz@juniper.net>
>> > > 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
>> > > BIER@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/bier
>>
>