Subject: [Bier] Comment on draft-ietf-bier-ospf-bier-extensions-17.txt // RE: I-D Action: draft-ietf-bier-ospf-bier-extensions-17.txt

From: Senthil Dhanaraj <[email-masked]>
Date: Wed, 4 Apr 2018 05:16:48 +0000

Hi Peter and Authors,

Have a suggestion !
It is better if we could clearly state the procedure to select the "BIER parameters to use" when the same BFR (a.k.a IGP) prefix is advertised by multiple BFR's.

Text from OSPF RFC 7684,  2.1.  OSPFv2 Extended Prefix TLV

   If this TLV is advertised multiple times for the same prefix in
   different OSPFv2 Extended Prefix Opaque LSAs originated by different
   OSPFv2 routers, the application using the information is required to                      // SEN1
   determine which OSPFv2 Extended Prefix Opaque LSA is used.  For
   example, the application could prefer the LSA providing the best path
   to the prefix.

// SEN1: Leave it to specific applications (like SR, BIER) to determine the rule.

Text from draft-ietf-ospf-segment-routing-extensions-24, 7.2.  Inter-area Segment routing in OSPFv2

   The Prefix-SID Sub-TLV will be included in this LSA and the Prefix-
   SID value will be set as follows:

      The ABR will look at its best path to the prefix in the source                                    // SEN2 
      area and find the advertising router associated with the best path
      to that prefix.

      The ABR will then determine if such router advertised a Prefix-SID                  
      for the prefix and use it when advertising the Prefix-SID to other
      connected areas.

      If no Prefix-SID was advertised for the prefix in the source area                           // SEN3
      by the router that contributes to the best path to the prefix, the
      originating ABR will use the Prefix-SID advertised by any other
      router when propagating the Prefix-SID for the prefix to other
      areas.

// SEN2: Select the Prefix-SID TLV from the router which has best path  
// SEN3: If the router which has best path to the prefix does not advertise Prefix-SID TLV, then select the other        

In fact there are two cases here,
Case-1: Different routers advertising same prefix with same BIER parameters
Case-2: Different routers advertising same prefix with different BIER parameters (ex: bfr-id is different)

Though the SR draft specified this procedure only with respect to case-1 and in the context of "Inter-Area" flooding, 
I believe case-1 & case-2 is applicable for Intra-Area as well to let the BFR choose one advertising-router or ignore the prefix.

My suggestion is,

Case-1:  Add a text to draft, specify the BFR MUST choose the prefix from a advertising router which has best path to the prefix
Case-2:  Do not consider the BFR prefix as valid unless the configuration issue is resolved.

Thanks,
Senthil

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 April 2018 21:25
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] I-D Action: draft-ietf-bier-ospf-bier-extensions-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF.

        Title           : OSPFv2 Extensions for BIER
        Authors         : Peter Psenak
                          Nagendra Kumar
                          IJsbrand Wijnands
                          Andrew Dolganow
                          Tony Przygienda
                          Jeffrey Zhang
                          Sam Aldrin
	Filename        : draft-ietf-bier-ospf-bier-extensions-17.txt
	Pages           : 11
	Date            : 2018-04-03

Abstract:
   Bit Index Explicit Replication (BIER) is an architecture that
   provides multicast forwarding through a "BIER domain" without
   requiring intermediate routers to maintain multicast related per-flow
   state.  Neither does BIER require an explicit tree-building protocol
   for its operation.  A multicast data packet enters a BIER domain at a
   "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
   one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router
   adds a BIER header to the packet.  Such header contains a bit-string
   in which each bit represents exactly one BFER to forward the packet
   to.  The set of BFERs to which the multicast packet needs to be
   forwarded is expressed by the according set of bits set in BIER
   packet header.

   This document describes the OSPF [RFC2328] protocol extension
   required for BIER with MPLS encapsulation [RFC8296].  Support for
   other encapsulation types is outside thescope of this document.  The
   use of multiple encapsulation types is outside the scope of this
   document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bier-ospf-bier-extensions-17
https://datatracker.ietf.org/doc/html/draft-ietf-bier-ospf-bier-extensions-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-ospf-bier-extensions-17

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/

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