Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06

Tony Przygienda <tonysietf@gmail.com> Mon, 08 May 2017 16:12 UTC

Return-Path: <tonysietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE01294E6; Mon, 8 May 2017 09:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_lcEl6lzu_Q; Mon, 8 May 2017 09:12:20 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBE9126C0F; Mon, 8 May 2017 09:12:19 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id b84so60349295wmh.0; Mon, 08 May 2017 09:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lfVVbylDNYlbAd3To5wJKF4engt4ltWsUrWpKOpERGY=; b=I7aDi1PcNkkV3SbzZFILWu4+QuxJDzP0mlcnzsQdfuKDiNTqLUenSAsffc9M8E5+Qq 7Rb3vdUtTXxg8zb27hTNutZ7X/CY5cIwTHBaRknsmQ2HWIVcZ2xi/i5JamMBLbpz3CXd 2gVQ3SlQ2S1t3gqgtLAN5a7B6B3comJwlyB7rn9C163KYj6RLY8vtOqgacU+bqdLNb2k kvy5Cko0uJ1yQ0YBahL6/Uy7PHzVkyjj6sB4sLUEA+XCTU/z4atX1dGVPJJdZMZD5wo+ 49yvPeEcoosnxBezcOOYMY7Ee8Dw99EtnCd3W2S7IPntDWjHZ7P5aB57YZrmbDdPsfzN /pKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lfVVbylDNYlbAd3To5wJKF4engt4ltWsUrWpKOpERGY=; b=aIuNoiOdbu3bBoN9UVa+L4Zu0JdETqDnq2XVA0OWj8oil0Y2x1ieJewMeXglz5ZkfZ L0V4Eo3sl19+lim/aQ8pdnDUyqY2Q4G5jXX5Hb/R6cCYxr9yoMw7Sxven+4juxH+pM/y bmjGc/nMHszEIAMTdXg86OnhOoX6I/55Ze6ONteNCQqEFsWETPUgDI0vdGg7Xmqcokjc wq6/FJxk4ilnLBkx3d1BdYypAJsD5kz4a5fnZjEz6pl6DJJEGpIc9+1cdSNzPafvobBB ckyOj5tT2xygWu/vsl77sPUl2EabLSh6sTxNKq78AT1yRyQjDzLllwIRBoMnyOtEGy2Q zsZA==
X-Gm-Message-State: AN3rC/6tOtlF/rkLwp7DWms99Y3pYrQI5JLK3jbQ5N7ufbm+/tYvlWGC 4kjstjjRuj/MmvshEBzpmHkG0NujoQ==
X-Received: by 10.80.212.211 with SMTP id e19mr19749368edj.164.1494259938014; Mon, 08 May 2017 09:12:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.159.37 with HTTP; Mon, 8 May 2017 09:11:37 -0700 (PDT)
In-Reply-To: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net>
References: <CABFReBq1xG4+qjS5roHDSgBaSSMd6dDA0au_FgKCKm9a0pSvOA@mail.gmail.com> <ba9d5fb2-81ba-63d7-b814-c94d154402dc@gmail.com> <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 8 May 2017 09:11:37 -0700
Message-ID: <CA+wi2hMUvNgOF65eQVH_T44+hYJxadDhw9Ohojka_Z51pEU+5Q@mail.gmail.com>
To: Eric C Rosen <erosen@juniper.net>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "bier@ietf.org" <bier@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c1af9f8cebc4f054f05808e
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/gA2XZigyMcxmMukBib0l_RMNU-o>
Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2017 16:12:22 -0000

My initial reaction was same as Eric's. You either have outer stack =
tunnel in which case what's inside is irrelevant (well, we know about deep
inspection hacks but that doesn't apply here) or the label/tag is BIER. if
the label is BIER it's processed by definition by a BFR that uses BIER
entropy ...

I have no opinion whether e.g. BIER entropy should be copied onto outer
stack in case BIER is tunneled in MPLS and I consider it an implementation
choice really since I don't see a need for the architecture to mandate this
...

--- tony

On Mon, May 8, 2017 at 8:29 AM, Eric C Rosen <erosen@juniper.net> wrote:

> Hi Stewart,
>
> Thanks for your review!
>
> On 5/8/2017 10:52 AM, Stewart Bryant wrote:
>
>>
>> Please could you clarify whether this document is being reviewed by the
>> MPLS WG as part of this process?
>>
>>
> I'll let the WG chairs answer that ;-)
>
> Please can you explain how the entropy system works in MPLS?
>>
>> Are you expecting the P router to look into the BIER header, or are you
>> expecting BIER capable nodes to construct an entropy structure in the outer
>> label stack.
>>
>>
> A router that is BIER-capable uses the entropy value from the BIER header
> as part of its BIER forwarding process.  This is discussed in the BIER
> architecture document.
>
> If a packet is being tunneled from one BIER-capable router to another, and
> the tunnel passes through a sequence of intermediate routers, then the
> tunnel encapsulation probably has some entropy mechanism of its own.  It
> would make sense to ensure that if two BIER packets have the same entropy
> value in their respective BIER headers, then they have the same entropy in
> the tunnel encapsulation.  However, the tunnel encapsulation is not the
> BIER encapsulation. and how the tunnel encapsulation header is formed is
> outside the scope of this document.
>
> The BIER entropy field does happen to be 20 bits long, so if the tunnel
> encapsulation is MPLS, the BIER entropy could be copied into the EL.
>
> If the latter, you have two methods available to you the EL system, and
>> the FAT PW system. The former is becoming the method of choice where
>> available, but you have the option of using the later which will work in
>> any network.
>>
>>
> This seems like a general issue about MPLS tunnels, not a BIER-specific
> issue.
>
> I find the title a little strange since the union of MPLS and non-MPLS is
>> all networks and thus you ought to cut the title after "Replication".
>>
>>
>>
> Originally the draft only discussed MPLS networks.  When a non-MPLS encaps
> was added, the title was augmented with "and non-MPLS networks".  I don't
> really see a problem with it, as it emphasizes that two encapsulation
> mechanisms are provided.
>
> Eric
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>



-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky