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

Xiejingrong <> Tue, 06 November 2018 04:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6ED8130E1C; Mon, 5 Nov 2018 20:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TUfNFqw0QPQp; Mon, 5 Nov 2018 20:55:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1653130E39; Mon, 5 Nov 2018 20:55:19 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 786F8E09C5DB4; Tue, 6 Nov 2018 04:55:16 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 04:55:16 +0000
Received: from ([fe80::40a8:f0d:c0f3:2ca5]) by ([]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 12:55:07 +0800
From: Xiejingrong <>
To: "Tarek Saad (tsaad)" <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: draft-xie-mpls-rsvp-bier-extension
Thread-Index: AQHUdX7aakcCQ7cHAUqUxoEC8GyjNqVCKXQQ
Date: Tue, 6 Nov 2018 04:55:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99B2B913nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [mpls] draft-xie-mpls-rsvp-bier-extension
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 04:55:25 -0000

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.


From: Tarek Saad (tsaad) []
Sent: Tuesday, November 6, 2018 10:15 AM
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?