Re: [mpls] draft-xie-mpls-rsvp-bier-extension

[Xiejingrong <[e-mail]>]

Hi Tarek,

Very good concern, and I have copy to BIER WG too.

There is useful description in the BIER-arch RFC8279 too:
   Alternatively, one could deploy a routing underlay that creates a
   multicast-specific tree of some sort.  BIER could then be used to
   forward multicast data packets along the multicast-specific tree,
   while unicast packets follow the "ordinary" OSPF best path.  (In a
   case like this, many multicast flows could be traveling along a
   single tree, and the BitString carried by a particular packet would
   identify those nodes of the tree that need to receive that packet.)
   It is even possible to have multiple routing underlays used by BIER,
   as long as one can infer from a data packet's BIER encapsulation
   which underlay is being used for that packet.

Even in BIER WG, there is no doubt about whether it is ARCH violation.
They said it make things complex when using a tree-building protocol.
But without the already existed, widely deployed, well proven, protocol-independent tree-building protocol,
many efforts intended to solve raised problems turns out to make things more complex.

That’s what the drafts about ‘multicast-specific tree based BIER’ want to do.
The standard encapsulation of RFC8296 allows a combination with P2MP obviously too ---- it is the architecture of MPLS.

So summary, no violation with BIER-ARCH, and fully compatible with BIER-MPLS-Encapsulation.

Thanks
Jingrong

From: Tarek Saad (tsaad) [mailto:[e-mail]]
Sent: Tuesday, November 6, 2018 10:15 AM
To: [e-mail]
Cc: [e-mail]
Subject: draft-xie-mpls-rsvp-bier-extension

Hi authors,

I have a high-level question related to the motivation of the work in “draft-xie-mpls-rsvp-bier-extension”.
The BIER architecture RFC8279 states that no protocol is needed to setup the tree, no per flow state is maintained in the network.. My understanding is in your case, you are using RSVP to building and maintaining a session per P2MP tree.

“However, it does not require a protocol for explicitly building multicast
distribution trees, nor does it require intermediate nodes to maintain any per-flow state.”

Also, the BIER-TE architecture document draft-ietf-bier-te-arch insists that it is more SR-like in nature in that explicit need for tree building and less like RSVP-TE in need to build a P2MP tree on per demand basis:

“Because BIER-TE like BIER operates without explicit in-network tree-building but also
supports traffic engineering, it is more similar to Segment Routing (SR) than RSVP-TE.”

Do you think the approach you are proposing will violate the above assumptions?

Regards,
Tarek