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

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 7 Dec 2018 15:53:18 +0000

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