Subject: [Rtg-dt-encap-considerations] [Bier] Encapsulation first nibble

From: Albert Tian <[email-masked]>
Date: Wed, 25 Mar 2015 05:05:50 +0000

This thread in bier mailing list is of interest to us. We should capture the first nibble issue in our next version.

Erik, if we are going to present in BIER please be aware of this discussion.

Thanks,
Albert

Subject: Re: [Bier] Encapsulation first nibble
From: Stewart Bryant <[email-masked]>
To: Ignas Bagdonas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, BIER <[email-masked]>, "[email-masked]" <[email-masked]>, Antoni Przygienda <[email-masked]>, "IJsbrand Wijnands (iwijnand)" <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Xuxiaohu <[email-masked]>, Eric Rosen <[email-masked]>
Date: Thu, 19 Mar 2015 10:57:48 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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

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

Subject: Re: [Bier] Encapsulation first nibble
From: "Stewart Bryant (stbryant)" <[email-masked]>
To: Ignas Bagdonas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, BIER <[email-masked]>, "[email-masked]" <[email-masked]>, Antoni Przygienda <[email-masked]>, "IJsbrand Wijnands (iwijnand)" <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Xuxiaohu <[email-masked]>, Eric Rosen <[email-masked]>
Date: Thu, 19 Mar 2015 07:41:08 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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,
> 
> > 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

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

Subject: Re: [Bier] Encapsulation first nibble
From: Ignas Bagdonas <[email-masked]>
To: Xuxiaohu <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Antoni Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rosen <[email-masked]>, BIER <[email-masked]>, IJsbrand Wijnands <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Mar 2015 01:51:20 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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

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

Subject: Re: [Bier] Encapsulation first nibble
From: Xuxiaohu <[email-masked]>
To: "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Antoni Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rosen <[email-masked]>, BIER <[email-masked]>, IJsbrand Wijnands <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Mar 2015 14:20:10 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

Hi Jeffrey,

> -----邮件原件-----
> 发件人: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
> 发送时间: 2015年3月18日 21:53
> 收件人: Xuxiaohu; Antoni Przygienda; [email-masked]; Eric Rosen;
BIER;
> IJsbrand Wijnands
> 抄送: [email-masked]; [email-masked]
> 主题: RE: [Bier] Encapsulation first nibble
> 
> 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.

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.

> Coupled with the reasons that Eric gave:
> 
> > 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.
> 
> I would think the encap-specific nibble is quite reasonable, and better
than a
> special purpose 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.

Best regards,
Xiaohu

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

Subject: Re: [Bier] Encapsulation first nibble
From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
To: Xuxiaohu <[email-masked]>, Antoni Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rosen <[email-masked]>, BIER <[email-masked]>, IJsbrand Wijnands <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 18 Mar 2015 13:52:30 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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.

Coupled with the reasons that Eric gave:

> 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.

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

Jeffrey

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

Subject: Re: [Bier] Encapsulation first nibble
From: IJsbrand Wijnands <[email-masked]>
To: Xuxiaohu <[email-masked]>
Cc: BIER <[email-masked]>, Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 16:11:52 -0700
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

Hi Xiaohu,

>> Why don¹t we reserve IP version value ¹15¹ and mark it as
OExtended Version
>> Type¹. This value indicates that the next nibble is the
OExtended 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:)

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.

> 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 Oproto¹
>> field. I think
we could easily carve out a part of the Oreserved¹ field at the
>> bottom of
the encoding and move Oproto¹ into it.  The Oproto¹ 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.
>>> On 13 Mar
2015, at 12:53, Stewart Bryant <[email-masked]> wrote:
>>> On
13/03/2015 19:46, Eric C Rosen wrote:
>>>> 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.
_______________________________________________
>>>> 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
_______________________________________________
>>> BIER mailing list
[email-masked]
>>> https://www.ietf.org/mailman/listinfo/bier
>> 
>>
_______________________________________________
>> BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

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

Subject: Re: [Bier] Encapsulation first nibble
From: Xuxiaohu <[email-masked]>
To: Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 21:44:03 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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]
> 主题: Re: [Bier] Encapsulation first nibble
> 
> 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,

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.
> 
> So I don't think BIER justifies the use of a new MPLS special purpose
> payload-protocol-identifier label.

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.

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

Subject: Re: [Bier] Encapsulation first nibble
From: Antoni Przygienda <[email-masked]>
To: "Zhaohui (Jeffrey) Zhang" <[email-masked]>, Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rosen <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 17:38:28 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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

--- tony 

> -----Original Message-----
> From: Zhaohui (Jeffrey) Zhang [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2015 10:36 AM
> To: Antoni Przygienda; Xuxiaohu; [email-masked]; Eric Rosen; BIER
> Cc: [email-masked]; [email-masked]
> 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.
> 

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

Subject: Re: [Bier] Encapsulation first nibble
From: "Zhaohui (Jeffrey) Zhang" <[email-masked]>
To: Antoni Przygienda <[email-masked]>, Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Rosen <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 17:35:40 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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
> 
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

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

Subject: Re: [Bier] Encapsulation first nibble
From: Antoni Przygienda <[email-masked]>
To: Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>, Eric C Rosen <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 17:15:31 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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 

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

Subject: Re: [Bier] Encapsulation first nibble
From: Eric C Rosen <[email-masked]>
To: Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>
Date: Tue, 17 Mar 2015 13:11:04 -0400
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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.

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

Subject: Re: [Bier] Encapsulation first nibble
From: IJsbrand Wijnands <[email-masked]>
To: <[email-masked]>
Cc: BIER <[email-masked]>, Eric C Rosen <[email-masked]>
Date: Tue, 17 Mar 2015 07:52:50 -0700
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

Hi Folks,

Why don¹t we reserve IP version value ¹15¹ and mark it as
OExtended Version Type¹. This value indicates that the next nibble is the
OExtended 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 Oproto¹ field. I think we could easily carve out a part of the
Oreserved¹ field at the bottom of the encoding and move Oproto¹ into it.
The Oproto¹ 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:
> On 13/03/2015
19:46, Eric C Rosen wrote:
>> 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.
_______________________________________________
>> 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
> 
> _______________________________________________
> BIER mailing
list
> [email-masked]
https://www.ietf.org/mailman/listinfo/bier

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

Subject: Re: [Bier] Encapsulation first nibble
From: Xuxiaohu <[email-masked]>
To: Xuxiaohu <[email-masked]>, "[email-masked]" <[email-masked]>, Eric C Rosen <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 11:17:04 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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

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

On 13/03/2015 19:46, Eric C Rosen wrote:
> 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.
>
>
>
> _______________________________________________
> 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

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

Subject: Re: [Bier] Encapsulation first nibble
From: Xuxiaohu <[email-masked]>
To: "[email-masked]" <[email-masked]>, Eric C Rosen <[email-masked]>, BIER <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2015 10:49:21 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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

On 13/03/2015 19:46, Eric C Rosen wrote:
> 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.
>
>
>
> _______________________________________________
> 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

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

Subject: Re: [Bier] Encapsulation first nibble
From: Stewart Bryant <[email-masked]>
To: Eric C Rosen <[email-masked]>, BIER <[email-masked]>
Date: Fri, 13 Mar 2015 19:53:34 +0000
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

On 13/03/2015 19:46, Eric C Rosen wrote:
> 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.
>
>
>
> _______________________________________________
> 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

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

Subject: [Bier] Encapsulation first nibble
From: Eric C Rosen <[email-masked]>
To: BIER <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 13 Mar 2015 15:46:15 -0400
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>

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.

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Mar 2015 11:10:39 -0500

On 3/25/15 12:05 AM, Albert Tian wrote:
> This thread in bier mailing list is of interest to us. We should 
> capture the first nibble issue in our next version.

Albert,

Isn't this a BIER specific issue as it relates to a specific transport?

Perhaps other encaps that want to use that transport would run into the 
same issue; is that the reason to elevate it to a general encaps issue?

Thanks,
    Erik

---

From: Alia Atlas <[email-masked]>
Date: Wed, 25 Mar 2015 16:49:44 -0400

It's an issue for a non-IP encapsulation or at least for any inside MPLS
encapsulation.
PWE3 ran into it - which is why there is a control-word.

If there is energy and willingness, considering what additional issues
apply to encapsulations
over MPLS would be quite useful.

I've heard a lot of good feedback about the draft that you've done.

Thanks,
Alia

On Wed, Mar 25, 2015 at 12:10 PM, Erik Nordmark <[email-masked]> wrote:

>> This thread in bier mailing list is of interest to us. We should capture
>> the first nibble issue in our next version.
>>
>
> Albert,
>
> Rtg-dt-encap-considerations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>