Re: [mpls] [Bier] Encapsulation first nibble

[Xuxiaohu <[e-mail]>]

Hi Eric,

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

> -----邮件原件-----
> 发件人: Eric C Rosen [mailto:[e-mail]]
> 发送时间: 2015年3月18日 1:11
> 收件人: Xuxiaohu; [e-mail]; BIER
> 抄送: [e-mail]; [e-mail]; [e-mail]
> 主题: 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.