Subject: [Bier] MPLS encapsulation

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Sep 2014 16:11:17 +0100

Hello biery people,

I have been scanning
https://datatracker.ietf.org/doc/draft-wijnands-mpls-bier-encapsulation/ and I
have three questions.

I ask these more in the spirit of discovery than because I have a particular
view, so I'll be happy to plant the questions and see you all go off and debate.

1. Bier in the middle of a stack.
As I read the draft, if I have MPLS payload over Bier multicast then I would...
Set bottom of stack in the special purpose label, include Bier header, set "next
protocol" to MPLS.

2. Stacked Bier
Could I set the Bier "next protocol" to Bier?

3. Why a special purpose label rather than a control word?
Since you are already hitting the bottom of stack, wouldn't using the control
word be more consistent?

Cheers,
Adrian

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Sep 2014 12:47:32 -0400

Adrian,

I'm a little confused about your question: are you using the term "special
purpose label" in the sense of RFC 7274 ("Allocating and Retiring
Special-Purpose MPLS Labels")?  If so, there is no use of special purpose
labels (in this sense) being proposed.

Did I misunderstand your question?

Eric

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 26 Sep 2014 17:54:35 +0000

Adrian,

It's not a special purpose label, but its semantics (local to the receiving router) is that a BIER header follows, and it's tied to a <SI, topology> tuple.

Jeffrey

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, September 26, 2014 12:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Bier] MPLS encapsulation
> 
> Adrian,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Sep 2014 23:55:22 +0100

Sorry Eric,

> Since you are already hitting the bottom of stack, wouldn't
> using the control word be more consistent?

Bad choice of words. I was hung up on how he label used is "special" and has
been "specially" designated and advertised. I would have done better to have
been more specific and said "BIER-MPLS" label since that is the term used in
section 2 of the I-D.

My point is that you are advocating the advertisement of a block of labels by
the IGP, and the use of one or more labels on the MPLS stack. And my question:
why do this? You could hit the bottom of stack as normal, use the control word
to identify BIER and put all of the information you need (currently deduced from
the BIER-MPLS label(s) ) into the BIER header.

I'm not saying that would be better. Just asking why the choice you have made.

Cheers,
Adrian

> Sent: 26 September 2014 17:48
> To: [email-masked]
> Cc: [email-masked]

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sat, 27 Sep 2014 12:39:14 +0200

Hi Adrian,

> the BIER-MPLS label(s) ) into the BIER header.

Just one clarification, in normal operation, we expect just one BIER label to be on the stack. Unless we sent a BIER packet over a P2P/FRR LSP, then you’ll see two. But for the BIER procedures, only the BIER label is relevant.

> I'm not saying that would be better. Just asking why the choice you have made.

Right, but the control word also has to be indicated by the top label, right? How would the forwarding plane otherwise know a control word is following at the bottom of the stack... So, using the control would just mean an additional indirection, while we can have a immediate indirection with a BIER-MPLS label.

Thx,

Ice.

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

---

From: Xuxiaohu <[email-masked]>
Date: Sun, 28 Sep 2014 05:11:06 +0000

> From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
> Sent: Saturday, September 27, 2014 6:39 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > My point is that you are advocating the advertisement of a block of
> > labels by the IGP, and the use of one or more labels on the MPLS stack. And my
> question:
> > why do this? You could hit the bottom of stack as normal, use the
> > control word to identify BIER and put all of the information you need
> > (currently deduced from the BIER-MPLS label(s) ) into the BIER header.

I'm in favor of Adrian's proposal of putting all of the information you need (i.e., SI and MT-ID information which is currently deduced from the BIER-MPLS label) into the BIER header.

> Just one clarification, in normal operation, we expect just one BIER label to be on
> the stack. Unless we sent a BIER packet over a P2P/FRR LSP, then you'll see two.
> But for the BIER procedures, only the BIER label is relevant.
> 
> Right, but the control word also has to be indicated by the top label, right? How
> would the forwarding plane otherwise know a control word is following at the
> bottom of the stack... So, using the control would just mean an additional
> indirection, while we can have a immediate indirection with a BIER-MPLS label.

Provided the SI and MT-ID information is carried within the BIER header, it seems that you only need a way to indicate the MPLS payload is a BIER.

Best regards,
Xiaohu

> >> I'm a little confused about your question: are you using the term
> >> "special purpose label" in the sense of RFC 7274 ("Allocating and
> >> Retiring Special-Purpose MPLS Labels")?  If so, there is no use of
> >> special purpose labels (in this sense) being proposed.
> >>

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 28 Sep 2014 05:23:22 +0000

I'm not sure whether the discussion is about MPLS encaps for BIER or  any BIER encaps. 

For MPLS, one (very good reason) is that we do have _very_ fast MPLS label lookup fast-paths, we do not have MT-ID & Set-ID lookup engines.  SetID is arguable as being in encaps but a label representing a set in MPLS is simply extremely natural to MPLS. MT-ID has actually no business in the fast-path I would say, the scope of validity of MT-ID is in the IGP control plane only. Building very complicated networking devices has a lot to do with NOT having all concepts showing in every piece of software and hardware, something also known as rule 5 of RFC1925.  

Having said that, different encapsulations (BIER over Avian Carriers) can and will be written and there is nothing that precludes such an encapsulation to carry arbitrary amount of information on the packet to be processed. 

As to MPLS ranges, this is something that is fashionable these days, IMO each set should have a completely independent label on it but there are trade-offs in terms of control plane complexity/protocol packet sizes vs. fast-path complexity vs. what people already have in silicon and so on. 

thanks 

--- tony 

> From: BIER [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Saturday, September 27, 2014 10:11 PM
> To: IJsbrand Wijnands; [email-masked]
> > > control word to identify BIER and put all of the information you
> > > need (currently deduced from the BIER-MPLS label(s) ) into the BIER
> header.
> 
> I'm in favor of Adrian's proposal of putting all of the information you need
> (i.e., SI and MT-ID information which is currently deduced from the BIER-
> MPLS label) into the BIER header.
> 
> > Just one clarification, in normal operation, we expect just one BIER
> > label to be on the stack. Unless we sent a BIER packet over a P2P/FRR LSP,
> then you'll see two.
> > > I'm not saying that would be better. Just asking why the choice you
> > > have
> > made.
> >
> > Right, but the control word also has to be indicated by the top label,
> > right? How would the forwarding plane otherwise know a control word is
> > following at the bottom of the stack... So, using the control would
> > just mean an additional indirection, while we can have a immediate
> indirection with a BIER-MPLS label.
> 
> Provided the SI and MT-ID information is carried within the BIER header, it
> seems that you only need a way to indicate the MPLS payload is a BIER.
> 
> Best regards,
> Xiaohu
> 
> > Thx,
> >
> > Ice.
> >
> > >
> > > Cheers,
> > > Adrian
> > >

---

From: Xuxiaohu <[email-masked]>
Date: Sun, 28 Sep 2014 08:01:39 +0000

> From: Antoni Przygienda [mailto:[email-masked]]
> Sent: Sunday, September 28, 2014 1:23 PM
> To: Xuxiaohu; IJsbrand Wijnands; [email-masked]
> Subject: RE: [Bier] MPLS encapsulation
> 

I'm talking about a generic BIER encapsulation which is transport-independent.

> For MPLS, one (very good reason) is that we do have _very_ fast MPLS label
> lookup fast-paths, we do not have MT-ID & Set-ID lookup engines.  SetID is

If I understand it correctly, the intention of the BIER-MPLS label lookup is to find the corresponding SI and MT-ID. By directly carrying the SI and MT-ID information in the BIER header, there is no need for that MPLS lookup at all even though that lookup is _very_ fast. Furthermore, there is no need any specific label distribution process for the BIER-MPLS-labels, especially IGP flooding-based distribution process. BTW, is it efficient to flood the BIER-MPLS-label bindings which are actually only meaningful to adjacent BFRs to all IGP peers within the whole IGP domain?

> arguable as being in encaps but a label representing a set in MPLS is simply
> extremely natural to MPLS. MT-ID has actually no business in the fast-path I
> would say, the scope of validity of MT-ID is in the IGP control plane only. Building

Disagree with the above argument. The MT-ID is not only useful in the IGP control plane but also useful in the data plane. Otherwise, how could a BFR determine which set of the IP forwarding table entries should be looked up for IP packet forwarding? Of course, MPLS-MT is a slightly different since the MPLS label itself could be used to indicate which MT's routing table should be used. However, to define a transport-independent BIER encapsulation, it's better for the MT-ID information to be contained in the BIER header. In addition, wouldn't the BIER-in-MAC be more prevalent than the BIER-in-MPLS provided the SI and MT-ID information is contained in the BIER header? IMHO, the only irreplaceable use case for BIER-in-MPLS is to use the IGP shortcut or FA for BIER-encapsulated packet forwarding.

> very complicated networking devices has a lot to do with NOT having all
> concepts showing in every piece of software and hardware, something also
> known as rule 5 of RFC1925.
> 
> Having said that, different encapsulations (BIER over Avian Carriers) can and will
> be written and there is nothing that precludes such an encapsulation to carry
> arbitrary amount of information on the packet to be processed.

How would you embed the SI and MT-ID in the Ethernet header? Or would you specify an Ethernet-specific BIER header?

> As to MPLS ranges, this is something that is fashionable these days, IMO each set
> should have a completely independent label on it but there are trade-offs in
> terms of control plane complexity/protocol packet sizes vs. fast-path complexity
> vs. what people already have in silicon and so on.

Since the BIER itself requires changes to both control plane and data plane anyway, I have not yet seen any significant advantage of the BIER-MPLS-label over a BIER header which contains MT-ID and SI information in those terms that you have mentioned above.

Best regards,
Xiaohu

> > > > My point is that you are advocating the advertisement of a block
> > > > of labels by the IGP, and the use of one or more labels on the
> > > > MPLS stack. And my
> > > question:
> > I'm in favor of Adrian's proposal of putting all of the information
> > you need (i.e., SI and MT-ID information which is currently deduced
> > from the BIER- MPLS label) into the BIER header.
> >
> > > > I'm not saying that would be better. Just asking why the choice
> > > > you have
> > > made.
> > >
> > > Right, but the control word also has to be indicated by the top
> > > label, right? How would the forwarding plane otherwise know a
> > > control word is following at the bottom of the stack... So, using
> > > the control would just mean an additional indirection, while we can
> > > have a immediate
> > Provided the SI and MT-ID information is carried within the BIER
> > header, it seems that you only need a way to indicate the MPLS payload is a
> BIER.
> >
> > Best regards,
> > Xiaohu
> >
> > > Thx,
> > >
> > > Ice.
> > >
> > > >
> > > > Cheers,
> > > > Adrian
> > > >
> > > >> Retiring Special-Purpose MPLS Labels")?  If so, there is no use
> > > >> of special purpose labels (in this sense) being proposed.
> > > >>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 28 Sep 2014 13:02:26 +0200

Hi Xuxiaohu,

> If I understand it correctly, the intention of the BIER-MPLS label lookup is to find the corresponding SI and MT-ID. By directly carrying the SI and MT-ID information in the BIER header, there is n…

All great points.

We always need some sort of encapsulation to store the BIER header. We can come up with a new ethertype potentially and skip MPLS. But why would we want to introduce yet an other encapsulation when MPLS can already solve the problem for us, and, provides great value IMO. Think about how we can stick a BIER MPLS packet over a LFA/TE FRR tunnel, etc… However, you still have a good point and we may work on other ways to encapsulate the BIER header. For that reason we have two drafts, and architecture draft and an encapsulation draft :-)

The label bindings are flooded indeed. There are features that can make use of knowing the labels of your neighbors.

> Disagree with the above argument. The MT-ID is not only useful in the IGP control plane but also useful in the data plane. Otherwise, how could a BFR determine which set of the IP forwarding table…

Lets not throw out the baby with the bath water. If MPLS is used to encapsulate the BIER header, lets also use the benefits that MPLS provides. If we make the BIER header more generic, we loose those advantages.

> Since the BIER itself requires changes to both control plane and data plane anyway, I have not yet seen any significant advantage of the BIER-MPLS-label over a BIER header which contains MT-ID and…

I think avoiding a SI & MT-ID lookup in the data plane by associating a different MPLS label with it is significant advantage, it simplifies the data-plane and make its faster.

Thx,

Ice.

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 28 Sep 2014 12:50:37 +0000

again, the discussion thread IMO to be meaningful needs to be split into 'mpls encapsualtion'  OR 'any transport encapsulation'.  I have difficulties to follow arguments made otherwise. 

I am not sure what 'transport independent encapsulation' would be and I think it would be interesting to understand whether 
BIER  is an L3 construct (like an IP frame) or it is an L2(.5) technology such as is MPLS. 

--- tony

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 29 Sep 2014 02:27:47 +0000

Hi Ice,

> From: IJsbrand Wijnands [mailto:[email-masked]]
> Sent: Sunday, September 28, 2014 7:02 PM
> To: Xuxiaohu
> Cc: Antoni Przygienda; [email-masked]; [email-masked]; [email-masked]
> >> For MPLS, one (very good reason) is that we do have _very_ fast MPLS
> >> label lookup fast-paths, we do not have MT-ID & Set-ID lookup
> >> engines.  SetID is
> >
> > If I understand it correctly, the intention of the BIER-MPLS label lookup is to
> find the corresponding SI and MT-ID. By directly carrying the SI and MT-ID
> information in the BIER header, there is no need for that MPLS lookup at all even
> though that lookup is _very_ fast. Furthermore, there is no need any specific
> label distribution process for the BIER-MPLS-labels, especially IGP flooding-based
> distribution process. BTW, is it efficient to flood the BIER-MPLS-label bindings
> which are actually only meaningful to adjacent BFRs to all IGP peers within the
> whole IGP domain?
> 
> All great points.
> 
> We always need some sort of encapsulation to store the BIER header. We can
> come up with a new ethertype potentially and skip MPLS. But why would we
> want to introduce yet an other encapsulation when MPLS can already solve the
> problem for us, and, provides great value IMO. Think about how we can stick a

No matter whether the MPLS shim is inserted or not, the BIER encapsulation is already there unless you want to use the MPLS shim header to encode the BitString as well. Therefore, by encoding the MT-ID and SI information in the BIER header and then encapsulating the BIER with the MAC header, you are actually reduce one encapsulation layer (i.e., the MPLS encapsulation layer), rather than introducing yet another encapsulation layer. 

> BIER MPLS packet over a LFA/TE FRR tunnel, etc... However, you still have a good

I fully agree there are use cases for BIER-over-MPLS. However, it doesn't mean you couldn't make the BIER encapsulation to be transport-independent.

> point and we may work on other ways to encapsulate the BIER header. For that
> reason we have two drafts, and architecture draft and an encapsulation draft :-)

That's great.

> knowing the labels of your neighbors.

In other words, the label bindings are only meaning to neighboring LSRs, right? If so, it doesn't make much sense to flood the label bindings within the IGP area or domain.

> >> arguable as being in encaps but a label representing a set in MPLS is
> >> simply extremely natural to MPLS. MT-ID has actually no business in
> >> the fast-path I would say, the scope of validity of MT-ID is in the
> >> IGP control plane only. Building
> >
> > Disagree with the above argument. The MT-ID is not only useful in the IGP
> control plane but also useful in the data plane. Otherwise, how could a BFR
> determine which set of the IP forwarding table entries should be looked up for
> IP packet forwarding? Of course, MPLS-MT is a slightly different since the MPLS
> label itself could be used to indicate which MT's routing table should be used.
> However, to define a transport-independent BIER encapsulation, it's better for
> the MT-ID information to be contained in the BIER header. In addition, wouldn't
> the BIER-in-MAC be more prevalent than the BIER-in-MPLS provided the SI and
> MT-ID information is contained in the BIER header? IMHO, the only
> irreplaceable use case for BIER-in-MPLS is to use the IGP shortcut or FA for
> BIER-encapsulated packet forwarding.
> 
> Lets not throw out the baby with the bath water. If MPLS is used to encapsulate

I'm not throwing out the baby with the bath water. On the contrary, I hope to decouple the baby (i.e., the BIER header) from the bath water (i.e., the transport header) :)

> the BIER header, lets also use the benefits that MPLS provides. If we make the
> BIER header more generic, we loose those advantages.

IMHO, the BIER-MPLS label doesn't bring you any real benefit: first, by using the BIER-MPLS label as an indicator for the MT-ID and SI instead of encoding the MT-ID and SI directly in the BIER-header, you would need additional lookup for the MT-ID and SI; second, you would have to define different BIER header formats for different transport technologies (e.g., BIER-over-MAC), unless you want to always use the BIER-in-MPLS for any other transports, in other words, you want to make the BIER header and the BIER-MPLS label as a mandatory combination for BIER forwarding in any case.; third, it seems that the encapsulation overhead is not reduced by using the MPLS-BIER label instead of encoding the MT-ID and SI in the BIER header.

> >> As to MPLS ranges, this is something that is fashionable these days,
> >> IMO each set should have a completely independent label on it but
> >> there are trade-offs in terms of control plane complexity/protocol
> >> packet sizes vs. fast-path complexity vs. what people already have in silicon
> and so on.
> >
> > Since the BIER itself requires changes to both control plane and data plane
> anyway, I have not yet seen any significant advantage of the BIER-MPLS-label
> over a BIER header which contains MT-ID and SI information in those terms that
> you have mentioned above.
> 
> I think avoiding a SI & MT-ID lookup in the data plane by associating a different
> MPLS label with it is significant advantage, it simplifies the data-plane and make
> its faster.

If I understand it correctly, at least the MT-ID lookup in the data plane could not be avoided by associated different MPLS label unless you could directly calculate the corresponding MT-ID according to certain rules.

Best regards,
Xiaohu

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 29 Sep 2014 03:38:29 +0000

> > We always need some sort of encapsulation to store the BIER header. We
> > can come up with a new ethertype potentially and skip MPLS. But why
> > would we want to introduce yet an other encapsulation when MPLS can
> > already solve the problem for us, and, provides great value IMO. Think
> > about how we can stick a
> 
> No matter whether the MPLS shim is inserted or not, the BIER encapsulation
> is already there unless you want to use the MPLS shim header to encode the
> BitString as well. Therefore, by encoding the MT-ID and SI information in the
> BIER header and then encapsulating the BIER with the MAC header, you are
> actually reduce one encapsulation layer (i.e., the MPLS encapsulation layer),
> rather than introducing yet another encapsulation layer.

 [Tony said]   Consider the 'label'  a simple mapping  of  <MT-ID,Domain-ID,Set-ID> -> Label. The mapping to label may become more complex later & the label will allow us to 'decouple' the speed of the forwarding from how complicated the necessary control plane gets.  And  you can do  MAC header with BIER encaps with label  instead of  carrying (MT-ID,Domain-ID,Set-ID) around which will need changing every time control plane e.g. extends set-id to be 2 bytes or something like this.  Yes, you need to swap the labels on every hop but that's the nature of today's fast lookup technologies like MPLS and well entrenched in present silicon. 

> > The label bindings are flooded indeed. There are features that can
> > make use of knowing the labels of your neighbors.
> 
> In other words, the label bindings are only meaning to neighboring LSRs,
> right? If so, it doesn't make much sense to flood the label bindings within the
> IGP area or domain.

 [Tony said]  You have to flood the encapsulation type, masklengths & BFR-ids 
anyway so you may as well put the label in there. It's 4 bytes only with range size. Observe 
other restrictions (e.g. label not being present) for the routers to compute
correct SPFs through all the domain (read the ISIS draft for it). Anyway,  
you would have to implement tons of new logic into OSPF to do link-local 
signaling correctly for this (and ISIS would need massive extensions unless I missed 
something new). 

--- tony