Subject: [Bier] Encapsulation first nibble

From: Eric C Rosen <[email-masked]>
Date: Fri, 13 Mar 2015 15:46:15 -0400

Here's a small issue for the WG to consider.

The mpls-bier-encapsulation draft specifies that the first nibble of the 
encapsulation is to be a BIER encaps version number, initially 0.  The 
values 4 and 6 are excluded from the "version number" space, as there 
are various heuristic procedures deployed that interpret those values of 
the first nibble following the MPLS label stack as identifying the 
payload to be an IP packet.

However, there are also various deployed heuristics that may interpret 
the values 0 and 1 as identifying a pseudowire payload, either data or OAM.

This raises the issue of whether we might be better off setting this 
nibble to a fixed value, rather than trying to use it as a version 
number.  If we really need a version number in the encaps, perhaps it 
should be someplace where it definitely won't impact any existing 
heuristics.   The safest value for the first nibble might be one of the 
values 5-9, which are already assigned as IP Version Numbers, but are 
assigned to things that (I think) don't actually exist.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Mar 2015 19:53:34 +0000

On 13/03/2015 19:46, Eric C Rosen wrote:
> The mpls-bier-encapsulation draft specifies that the first nibble of 
> the encapsulation is to be a BIER encaps version number, initially 0.  
> The values 4 and 6 are excluded from the "version number" space, as 
> there are various heuristic procedures deployed that interpret those 
> values of the first nibble following the MPLS label stack as 
> identifying the payload to be an IP packet.
>
> heuristics.   The safest value for the first nibble might be one of 
> the values 5-9, which are already assigned as IP Version Numbers, but 
> are assigned to things that (I think) don't actually exist.
>
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

I agree with Eric on this.

I would set the nibble to zero which tells any parser that the payload 
is only understandable only by a node that knows the actions required by 
the BOS label.

I think the ACH RFC says something like the above, but would have to go 
find the specific text.

- Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 10:49:21 +0000

I believe this should be applicable to the NSH as well (i.e., set the nibble to zero) if it's assumed that the NSH could be encapsulated within an MPLS packet. 

Best regards,
Xiaohu

-----邮件原件-----
发件人: BIER [mailto:[email-masked]] 代表 Stewart Bryant
发送时间: 2015年3月14日 3:54
收件人: Eric C Rosen; BIER
主题: Re: [Bier] Encapsulation first nibble

I would set the nibble to zero which tells any parser that the payload is only understandable only by a node that knows the actions required by the BOS label.

I think the ACH RFC says something like the above, but would have to go find the specific text.

- Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 11:17:04 +0000

Another way is to add a protocol identifier field after the bottom of the label stack (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-00). In this way, we would not be bothered about the nibble issue anymore when proposing any new encapsulation header which may be encapsulated within an MPLS packet.

Best regards,
Xiaohu

-----邮件原件-----
发件人: mpls [mailto:[email-masked]] 代表 Xuxiaohu
发送时间: 2015年3月17日 18:49
收件人: [email-masked]; Eric C Rosen; BIER
抄送: [email-masked]; [email-masked]
主题: Re: [mpls] [Bier] Encapsulation first nibble

Best regards,
Xiaohu

-----邮件原件-----
发件人: BIER [mailto:[email-masked]] 代表 Stewart Bryant
发送时间: 2015年3月14日 3:54
收件人: Eric C Rosen; BIER
主题: Re: [Bier] Encapsulation first nibble

- Stewart

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

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 17 Mar 2015 07:52:50 -0700

Hi Folks,

Why don’t we reserve IP version value ’15’ and mark it as ‘Extended Version Type’. This value indicates that the next nibble is the ‘Extended Version field', which indicates the payload that is following. This would be a more generic solution for other encapsulation that may be added in the future.

For BIER MPLS encapsulation it means we would need to move the ‘proto’ field. I think we could easily carve out a part of the ‘reserved’ field at the bottom of the encoding and move ‘proto’ into it.  The ‘proto’ field is only relevant after BIER processing is done, so there should not be a performance impact I think.

Thx,

Ice.

> On 13 Mar 2015, at 12:53, Stewart Bryant <[email-masked]> wrote:
> 
>> The mpls-bier-encapsulation draft specifies that the first nibble of the encapsulation is to be a BIER encaps version number, initially 0.  The values 4 and 6 are excluded from the "version number" space, as there are various heuristic procedures deployed that interpret those values of the first nibble following the MPLS label stack as identifying the payload to be an IP packet.
>> 
>> However, there are also various deployed heuristics that may interpret the values 0 and 1 as identifying a pseudowire payload, either data or OAM.
>> 
>> This raises the issue of whether we might be better off setting this nibble to a fixed value, rather than trying to use it as a version number.  If we really need a version number in the encaps, perhaps it should be someplace where it definitely won't impact any existing heuristics.   The safest value for the first nibble might be one of the values 5-9, which are already assigned as IP Version Numbers, but are assigned to things that (I think) don't actually exist.
>> 
>> 
>>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 17 Mar 2015 13:11:04 -0400

On 3/17/2015 7:17 AM, Xuxiaohu wrote:
> Another way is to add a protocol identifier field after the bottom of
> the label stack
> (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-00).
> In this way, we would not be bothered about the nibble issue anymore
> when proposing any new encapsulation header which may be encapsulated
> within an MPLS packet.

When a BIER packet is traveling from BFIR to BFER via a sequence of 
directly connected BFRs, each BFR already knows, via the bottom label, 
that the packet is a BIER packet.  The nibble issue really only matters 
when a BIER packet is traveling through a non-BIER tunnel.

When a BIER packet is traveling through a non-BIER tunnel, some of the 
transit routers may be routers that are running older software.  They 
will base their ECMP treatment of the packet on the first nibble.  A 
protocol identifier field won't help, because these old routers won't 
understand it.  For newer routers, I think the proper direction is to 
use the MPLS entropy label, rather than to have each router compute the 
entropy based on an analysis of the next encapsulation header.

So I don't think BIER justifies the use of a new MPLS special purpose 
payload-protocol-identifier label.

There is one case though in which it could potentially be useful to 
enable the transit routers of a unicast MPLS tunnel to determine that a 
particular packet has a BIER payload.  Suppose thtat the MPLS TTL of the 
unicast tunnel expires while the packet is still in the tunnel.  It 
might be useful for the transit router to generate an ICMP response to 
the TTL expiration, and for this ICMP response to be BIER-aware. 
However, this is only likely to happen in a traceroute-like application, 
and I don't think that is sufficient justification for having all BIER 
packets carry the two or three extra label stack entries it would take 
to provide the special purpose payload-protocol-identifier label.  On 
the other hand, a nibble value specific to BIER might be useful, as it 
provides the same information without requiring additional overhead.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 17 Mar 2015 17:15:31 +0000

Not being much of an encapsulation, data plane guy myself, I wonder a tad how hacky those 'heuristics' are.  Last label indicates clearly a BIER header is following. For the LSRs that do not support BIER and do not parse the BIER encaps there is no reason to look 'behind the label'.  Multiple sub-domains allow for clean separation of traffic with different properties if needed and with that there is even less reason for some kind of 'heuristic' DPI

Now, given some 'heuristics' are in place no matter what value we put into the nibble, sooner or later we'll collide with it no matter what value we pick since such 'heuristics' basically try to parse bits without understanding their context and with that can easily mistake an 'eye' for an 'I' or an 'aye'. 

--- tony

---

From: "Zhaohui (Jeffrey) Zhang" <[email-masked]>
Date: Tue, 17 Mar 2015 17:35:40 +0000

Today those "heuristics" are typically used in very specific deployments where an operator knows well what kind of traffic is going through their MPLS infrastructure.

As Eric mentioned in the other message, a nibble value specific to BIER might be useful for other purpose than ECMP entropy, and if such a value is standardized (like value 0 and 1 that are reserved for PWs), then it helps reduce the clashing with random/hacky heuristics usages.

Jeffrey

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Antoni Przygienda
> Sent: Tuesday, March 17, 2015 1:16 PM
> To: Xuxiaohu; [email-masked]; Eric Rosen; BIER
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Bier] Encapsulation first nibble
> 
> Not being much of an encapsulation, data plane guy myself, I wonder a tad
> how hacky those 'heuristics' are.  Last label indicates clearly a BIER
> header is following. For the LSRs that do not support BIER and do not
> parse the BIER encaps there is no reason to look 'behind the label'.
> Multiple sub-domains allow for clean separation of traffic with different
> properties if needed and with that there is even less reason for some kind
> of 'heuristic' DPI
> 
> Now, given some 'heuristics' are in place no matter what value we put into
> the nibble, sooner or later we'll collide with it no matter what value we
> pick since such 'heuristics' basically try to parse bits without
> understanding their context and with that can easily mistake an 'eye' for
> an 'I' or an 'aye'.
> 
> --- tony
> 
> 
>

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 17 Mar 2015 17:38:28 +0000

Ok, point taken (as are the ECMP/ICMP things that Eric mentioned). I'll watch from the bleachers the data plane fireworks then  ;-) 

--- tony 

> From: Zhaohui (Jeffrey) Zhang [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2015 10:36 AM
> To: Antoni Przygienda; Xuxiaohu; [email-masked]; Eric Rosen; BIER
> Subject: RE: [Bier] Encapsulation first nibble
> 
> Today those "heuristics" are typically used in very specific deployments where an
> operator knows well what kind of traffic is going through their MPLS
> infrastructure.
> 
> As Eric mentioned in the other message, a nibble value specific to BIER might be
> useful for other purpose than ECMP entropy, and if such a value is standardized
> (like value 0 and 1 that are reserved for PWs), then it helps reduce the clashing
> with random/hacky heuristics usages.
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 21:44:03 +0000

Hi Eric,

Thanks a lot for your response. Please see my response inline.

> -----邮件原件-----
> 发件人: Eric C Rosen [mailto:[email-masked]]
> 发送时间: 2015年3月18日 1:11
> 收件人: Xuxiaohu; [email-masked]; BIER
> 抄送: [email-masked]; [email-masked]; [email-masked]
> When a BIER packet is traveling from BFIR to BFER via a sequence of directly
> connected BFRs, each BFR already knows, via the bottom label, that the packet
> is a BIER packet.  The nibble issue really only matters when a BIER packet is
> traveling through a non-BIER tunnel.

> When a BIER packet is traveling through a non-BIER tunnel, some of the transit
> routers may be routers that are running older software.  They will base their
> ECMP treatment of the packet on the first nibble.  A protocol identifier field
> won't help, because these old routers won't understand it.  For newer routers,

Since the nibble immediately after the Protocol Identifier Label (PIL) which is at the bottom of the label stack is set to zero, those old routers would not interpreted those packets containing a protocol id field as IP packets. Of course, if the MPLS payload is an IP packet, it could be encapsulated as before (i.e., w/o the protocol id field) . In other words, the protocol id field could be applicable to new payload types till those old routers have disappeared from the network.

> I think the proper direction is to use the MPLS entropy label, rather than to
> have each router compute the entropy based on an analysis of the next
> encapsulation header.
> 

The reason that I mentioned that approach is: for whatever new encapsulation header (e.g., BIER, NSH,...), as long as it has the possibility of being encapsulated within an MPLS packet, we would have to address the nibble issue when designing that new encapsulation header. I wonder why not the MPLS itself fixes its own drawback (i.e., the lack of the protocol field) so as to eliminate such bother forever. In addition, it could further eliminate the need for allocating and advertising labels for indicating these new MPLS payload types. For example, assume the NSH is to be encapsulated within an MPLS packet, the egress would have to allocate and advertise an application label for the NSH-encapsulated packet, just as what the MPLS-BIER label does. Of course, the MPLS-BIER label could be used to extract other BIER related info besides the payload type info.

Best regards,
Xiaohu

> There is one case though in which it could potentially be useful to enable the
> transit routers of a unicast MPLS tunnel to determine that a particular packet
> has a BIER payload.  Suppose thtat the MPLS TTL of the unicast tunnel expires
> while the packet is still in the tunnel.  It might be useful for the transit router
> to generate an ICMP response to the TTL expiration, and for this ICMP
> response to be BIER-aware.
> However, this is only likely to happen in a traceroute-like application, and I don't
> think that is sufficient justification for having all BIER packets carry the two or
> three extra label stack entries it would take to provide the special purpose
> payload-protocol-identifier label.  On the other hand, a nibble value specific to
> BIER might be useful, as it provides the same information without requiring
> additional overhead.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 21:51:21 +0000

Hi Jeffrey,

> -----邮件原件-----
> 发件人: Zhaohui (Jeffrey) Zhang [mailto:[email-masked]]
> 发送时间: 2015年3月18日 1:36
> 收件人: Antoni Przygienda; Xuxiaohu; [email-masked]; Eric Rosen; BIER
> 主题: RE: [Bier] Encapsulation first nibble
> 
> Today those "heuristics" are typically used in very specific deployments where
> an operator knows well what kind of traffic is going through their MPLS
> infrastructure.
> 
> As Eric mentioned in the other message, a nibble value specific to BIER might
> be useful for other purpose than ECMP entropy, and if such a value is
> standardized (like value 0 and 1 that are reserved for PWs), then it helps reduce
> the clashing with random/hacky heuristics usages.

Following such logic (i.e., assign a nibble value specific to the new encapsulation header), we would have to consider how many available nibble values are there which can be used for future encapsulation headers in the same way.

Best regards,
Xiaohu

> > Not being much of an encapsulation, data plane guy myself, I wonder a
> > tad how hacky those 'heuristics' are.  Last label indicates clearly a
> > BIER header is following. For the LSRs that do not support BIER and do
> > not parse the BIER encaps there is no reason to look 'behind the label'.
> > Multiple sub-domains allow for clean separation of traffic with
> > different properties if needed and with that there is even less reason
> > for some kind of 'heuristic' DPI
> >
> > Now, given some 'heuristics' are in place no matter what value we put
> > into the nibble, sooner or later we'll collide with it no matter what
> > value we pick since such 'heuristics' basically try to parse bits
> > without understanding their context and with that can easily mistake
> > an 'eye' for an 'I' or an 'aye'.
> >
> > --- tony
> >
> >
> >

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 22:07:03 +0000

Hi Ice,

> -----邮件原件-----
> 发件人: BIER [mailto:[email-masked]] 代表 IJsbrand Wijnands
> 发送时间: 2015年3月17日 22:53
> 收件人: [email-masked]
> 抄送: BIER; Eric C Rosen
> Why don’t we reserve IP version value ’15’ and mark it as ‘Extended Version
> Type’. This value indicates that the next nibble is the ‘Extended Version field',
> which indicates the payload that is following. This would be a more generic
> solution for other encapsulation that may be added in the future.

The above proposal reminds me of the ESP concept:)

Now the question is: should we leave the MPLS payload type indication work to the MPLS or each new MPLS payload type?

Best regards,
Xiaohu

> For BIER MPLS encapsulation it means we would need to move the ‘proto’
> field. I think we could easily carve out a part of the ‘reserved’ field at the
> bottom of the encoding and move ‘proto’ into it.  The ‘proto’ field is only
> relevant after BIER processing is done, so there should not be a performance
> impact I think.

If I understand it correctly, the original "protocol" field in the MPLS-BIER header is used to indicate the payload of the BIER packet ()

> encapsulation is to be a BIER encaps version number, initially 0.  The values 4
> and 6 are excluded from the "version number" space, as there are various
> heuristic procedures deployed that interpret those values of the first nibble
> following the MPLS label stack as identifying the payload to be an IP packet.
> >>
> >> However, there are also various deployed heuristics that may interpret the
> values 0 and 1 as identifying a pseudowire payload, either data or OAM.
> >>
> >> This raises the issue of whether we might be better off setting this nibble to
> a fixed value, rather than trying to use it as a version number.  If we really
> need a version number in the encaps, perhaps it should be someplace where it
> definitely won't impact any existing heuristics.   The safest value for the first
> nibble might be one of the values 5-9, which are already assigned as IP Version
> Numbers, but are assigned to things that (I think) don't actually exist.
> >>
> >>
> >>
> > I would set the nibble to zero which tells any parser that the payload is only
> understandable only by a node that knows the actions required by the BOS
> label.
> >

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Mar 2015 22:17:05 +0000

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2015年3月18日 6:11
> 收件人: 'IJsbrand Wijnands'; [email-masked]
> 抄送: BIER; Eric C Rosen
> 主题: 答复: [Bier] Encapsulation first nibble
> 
> Hi Ice,
> 
> > -----邮件原件-----
> > Why don’t we reserve IP version value ’15’ and mark it as ‘Extended
> > Version Type’. This value indicates that the next nibble is the
> > ‘Extended Version field', which indicates the payload that is
> > following. This would be a more generic solution for other encapsulation that
> may be added in the future.
> 

s/ESP/ESPL

Best regards,
Xiaohu

> > field. I think we could easily carve out a part of the ‘reserved’
> > field at the bottom of the encoding and move ‘proto’ into it.  The
> > ‘proto’ field is only relevant after BIER processing is done, so there
> > should not be a performance impact I think.
> 
> If I understand it correctly, the original "protocol" field in the MPLS-BIER header
> is used to indicate the payload of the BIER packet ()
> 
> > Thx,
> >
> > Ice.
> >
> >
> > are various heuristic procedures deployed that interpret those values
> > of the first nibble following the MPLS label stack as identifying the payload to
> be an IP packet.
> > >>
> > a fixed value, rather than trying to use it as a version number.  If
> > we really need a version number in the encaps, perhaps it should be
> someplace where it
> > nibble might be one of the values 5-9, which are already assigned as
> > IP Version Numbers, but are assigned to things that (I think) don't actually
> exist.
> > >>
> > >>
> > >>
> > understandable only by a node that knows the actions required by the
> > BOS label.
> > >
> > > I think the ACH RFC says something like the above, but would have to
> > > go find
> > the specific text.
> > >
> > > - Stewart
> > >

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 17 Mar 2015 16:11:52 -0700

Hi Xiaohu,

> The above proposal reminds me of the ESP concept:)

I would like to avoid having to process two extra labels before knowing how to forward the packet ;-)

(There are two labels for ESP, and one for BIER).

Since the BIER label will indicate what follows is a BIER header, there is no need to parse the Extended Version. So there is a significant difference with ESP.

I would like to allow a sniffer to be able to parse a BIER packet. Eric’s proposal would also work for that if we assign a value between 5 and 9 to BIER. 

Thx,

Ice.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 18 Mar 2015 13:52:30 +0000

Xiaohu,

> Following such logic (i.e., assign a nibble value specific to the new
> encapsulation header), we would have to consider how many available nibble
> values are there which can be used for future encapsulation headers in the
> same way.

There are still quite a few values left; defining a new encapsulation is not lightly taken; adding a new IP version is not lightly taken either. Besides, there is this "reserved value 15" idea from Ice.

> payload-protocol-identifier label.

I would think the encap-specific nibble is quite reasonable, and better than a special purpose label.

Jeffrey

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Mar 2015 14:20:10 +0000

Hi Jeffrey,

> -----邮件原件-----
> 发件人: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
> 发送时间: 2015年3月18日 21:53
> 收件人: Xuxiaohu; Antoni Przygienda; [email-masked]; Eric Rosen; BIER;
> IJsbrand Wijnands
> > encapsulation header), we would have to consider how many available
> > nibble values are there which can be used for future encapsulation
> > headers in the same way.
> 
> There are still quite a few values left; defining a new encapsulation is not lightly
> taken; adding a new IP version is not lightly taken either. Besides, there is this
> "reserved value 15" idea from Ice.

Since the control word is optional when transporting Ethernet over MPLS, I wonder whether the idea of reserving the first nibble value of 15 is feasible in practice.

> > I think the proper direction is to use the MPLS entropy label, rather
> > than to have each router compute the entropy based on an analysis of
> > the next encapsulation header.
> >

Due to the same reason as mentioned above, I wonder whether it's feasible to reserve a certain first nibble value as an encap-specific nibble in practice.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Mar 2015 14:56:39 +0000

> 发送时间: 2015年3月18日 22:20
> 收件人: Jeffrey (Zhaohui) Zhang; Antoni Przygienda; [email-masked]; Eric
> Rosen; BIER; IJsbrand Wijnands
> > 收件人: Xuxiaohu; Antoni Przygienda; [email-masked]; Eric Rosen;
> > BIER; IJsbrand Wijnands
> > > Following such logic (i.e., assign a nibble value specific to the
> > > new encapsulation header), we would have to consider how many
> > > available nibble values are there which can be used for future
> > > encapsulation headers in the same way.
> >
> > There are still quite a few values left; defining a new encapsulation
> > is not lightly taken; adding a new IP version is not lightly taken
> > either. Besides, there is this "reserved value 15" idea from Ice.
> 
> Since the control word is optional when transporting Ethernet over MPLS, I
> wonder whether the idea of reserving the first nibble value of 15 is feasible in
> practice.
> 
> > > I think the proper direction is to use the MPLS entropy label,
> > > rather than to have each router compute the entropy based on an
> > > analysis of the next encapsulation header.
> > >
> > > So I don't think BIER justifies the use of a new MPLS special
> > > purpose payload-protocol-identifier label.
> >
> Due to the same reason as mentioned above, I wonder whether it's feasible to
> reserve a certain first nibble value as an encap-specific nibble in practice.

More specifically, since it allows the Ethernet frames to be transported over MPLS networks w/o control word, any possible value of the first nibble may have been used. Of course, if the first nibble is immediately after a certain SPL or ESPL, it becomes possible to reserve a certain value of that nibble as a given encapsulation header (see https://tools.ietf.org/html/draft-guichard-sfc-metadata-header-00#page-4). However, in this case (i.e., an SPL or ESPL is used), it seems more straightforward to add a proto field after the first nibble, rather than using the first nibble itself as a poor-man's proto field.

---

From: Ignas Bagdonas <[email-masked]>
Date: Thu, 19 Mar 2015 01:51:20 +0000

Hi,

 > Since the control word is optional when transporting Ethernet over 
MPLS, I wonder whether the idea of reserving the first nibble value of 
15 is feasible in practice.

Not using a control word for ethernet PW is painful from operational 
perspective. Many deployed platforms will look past the labels without 
much context and if they happen to find 4 or 6 there, the behavior will 
range from blindly believing that it is in fact IPv4 or IPv6 packet to 
trying to validate certain fields or even checksums. Control word helps 
here, and if both sides have support, it should be used.

Ignas

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Thu, 19 Mar 2015 07:41:08 +0000

That is correct.

PWE3 took over the design after draft-martini had been widely adopted and deployed, otherwise PWs may well have been exclusively CW. The wide deployment of Ethernet PW without the CW means that PW OAM is more complicated than it would otherwise be - see the latest vcxo over GAL draft from PALS. It was asserted in the early days that there would not be a problem because there would never be an ethernet address issued that alias with the IPv4 first nibble. Well guess what happened? Yes they were and yes there was!

There is another way forward, require the inclusion of the ELI and exclusive use of ELI enabled LSPs, but in that case the packet size would go up by more than needed to fix BIER and the operational complexity would be significant, thus the cure would be worse than the disease.

Stewart 

Sent from my iPad

> On 19 Mar 2015, at 01:51, Ignas Bagdonas <[email-masked]> wrote:
> 
> 
> Hi,
> 
> Not using a control word for ethernet PW is painful from operational perspective. Many deployed platforms will look past the labels without much context and if they happen to find 4 or 6 there, the behavior will range from blindly believing that it is in fact IPv4 or IPv6 packet to trying to validate certain fields or even checksums. Control word helps here, and if both sides have support, it should be used.
> 
> Ignas
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Mar 2015 10:57:48 +0000

Re-my last email.

Aren't learning spell correctors annoying!  VCXO was supposed to be
VCCV.  Clearly my iPad feels itself to be more closely affiliated to my
radio interests than my PW interests :(

- Stewart