Re: [Bier] draft-ietf-bier-ipv6-requirements-09

[Loa Andersson <[e-mail]>]

Folks,

I tried to says this at the meeting. Sometimes back in the Stoneages, we 
startedto specify requiremens.

My manager at that time stressed over and over again, that requirements 
need to be:

- measurable
- verifiable
- testable


Looking at the L2 requirement from draft-ietf-bier-ipv6-requirements-09:

The solution should support various kinds of L2 data link types.

I'd say that should is bad requrement language, it should be "shall". 
Should normalle signifies a goal.

Various is also bad. The implementer needs to know how many. With 
various in the requirement it is possible that two implementations that 
support every other requirement, actually do not support any joint L2 
data link types and thus is incompatible.

Various is also bad because the implementer needs to know which L2 data 
link types.

What about:

The solution shall support the following two L2 data link types, 
Ethernet and HDLC.


/L2


On 29/11/2020 14:43, Gyan Mishra wrote:
> 
> Mike / All
> 
> As Jeffrey mentioned over the course of this detailed thread I flushed 
> out the understanding of BIERin6 and confirmed they no gaps exist.
> 
> As it stands today no changes related to the last contested item related 
> to “RFC 8296 L2 Ethernet” between myself and Jeffrey would change as the 
> BIERin6 draft as Jeffery has stated is an complete holistic solution for 
> an IPV6 environment.  This is a new development as I worked out in my 
> mind per below why L2 should be part of BIERin6 draft.
> 
> In order for BIERin6 draft to be holistic solution all encompassing of 
> requirements, it is required to have the existing RFC 8296 Non MPLS BIER 
> Ethernet with next header defined for BIER header 0xAB37, followed IPv6 
> payload, be part of the overall solution  - - this would used as the 
> primary solution for directly and non directly connected BFRs and the 
> “optional” solution would be BIERin6 which requires new next header for 
> BIER header following IPv6 encapsulation header and ICMP code point.  
> The optional BIERin6 would be used in cases where the operator requires 
> IPv6 tunneling or FRR.
> 
> As Jeffrey mentioned there is some text verbiage to be updated 
> pertaining to how the requirements are being met with BIERin6 solution.
> 
> Based on what Greg and Jeffrey have stated and my thorough review of 
> BIERin6 on ML I am in agreement that no gaps exist and that we just have 
> to ensure all verbiage is updated related to meeting any new or existing 
> requirements that maybe missing.
> 
> The key here in context  related to the requirements draft, BIERin6 will 
> satisfy all existing and any new requirements added to the draft, 
> however BIERin6 advancement is not dependent on the requirements draft.
> 
> The main reason for that is that the BIERin6 draft leverages existing 
> L2/tunnel RFC 8296 solution “Non MPLS BIER Ethernet” solution as the 
> primary solution for IPv6 environments.  The existing layering utilized 
> in Non MPLS BIER Ethernet is utilized in BIERin6 solution moving the 
> BIER header to inner header inside outer IPv6 header with identical 
> layering solution.
> 
> As BIERin6 IPv6 encapsulation solution utilizes the identical layering 
> style framework in essence by incorporating the existing L2 solution, it 
> makes the both solutions both homogeneous as well as holistic solution 
> by providing layering parity between the two solutions.  Another 
> important reason why the existing L2 solution should be part of the 
> BIERin6 draft.
> 
> As the requirements draft is independent of the BIERin6 draft it can and 
> should be finalized.  The work on the requirements draft is pertinent to 
> the BIERv6 solution and should continue.
> 
> Once BIERin6 is adopted we would need to determine what gaps exist with 
> BIERin6 that can be satisfied by BIERv6 and identify.
> 
> If we are able to clearly identify those BIERin6 gaps that BIERv6 meets 
> and fills those gaps, as well as  all the requirements are met then we 
> can seek WG adoption of BIERv6 draft  as well.
> 
> Kind Regards
> 
> Gyan
> 
> On Sat, Nov 28, 2020 at 4:53 PM Jeffrey (Zhaohui) Zhang 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     To clarify, there is no gap in the BIERin6 solution (besides the new
>     "next header" code point). It's just that some text are needed to
>     explain how the requirements are met with the BIERin6 solution -
>     whether it is a requirement already listed in the current
>     requirements draft, or have been brought up in recent mailing list
>     discussions (I know of two in recent discussions).
> 
>     BIERin6 is based on RFC 8296 (plus the new "next header" code point
>     for IPv6 encapsulation), and is a generic solution with the
>     following properties:
> 
>     1. clean layering - BIER over L2/tunnel and it can carry different
>     payload types including SRv6
>     2. IPv4/IPv6 independent (of course you need different signaling)
>     3. L2 independent - as long as the L2 header can indicate with a
>     code point that a BIER header follows
>     4. tunnel type independent - as long as the tunnel header can
>     indicate with a code point that a BIER header follows
>     5. can work one-hop or multi-hop tunnels nicely
>     6. can work with SRv6 based services nicely
> 
>     With the above, there is simply no need for another solution in my
>     view. Of course the WG can continue discussing BIERv6 and may
>     determine that it is nice to have BIERv6 as well, but we should not
>     bundle them together when it comes to adoption. That's why I
>     suggested in the last BIER session the following:
> 
>     - Adopt BIERin6
>     - Discuss BIERv6 further
> 
>     Jeffrey
> 
>     -----Original Message-----
>     From: Michael McBride <[e-mail]
>     <mailto:[e-mail]>>
>     Sent: Saturday, November 28, 2020 2:15 PM
>     To: [e-mail] <mailto:[e-mail]>; Jeffrey (Zhaohui)
>     Zhang <[e-mail] <mailto:[e-mail]>>
>     Cc: Gyan Mishra <[e-mail]
>     <mailto:[e-mail]>>; Alvaro Retana
>     <[e-mail] <mailto:[e-mail]>>; BIER WG
>     <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; Tony Przygienda
>     <[e-mail] <mailto:[e-mail]>>;
>     draft-ietf-bier-ipv6-requirements
>     <[e-mail]
>     <mailto:[e-mail]>>
>     Subject: RE: draft-ietf-bier-ipv6-requirements-09
> 
>     [External Email. Be cautious of content]
> 
> 
>     Hi Greg,
> 
>      >Thank you Jeffrey and Gyan for sticking with the thread of the
>     conversation to advance the discussion. It's clear now that all of
>     the requirements >discussed so far can be addressed by the BIERin6
>     draft if we flesh out the discussed gaps.
> 
>      >I would like to see Jeffrey and Gyan take over as primary authors of
>      >BIERin6 to include the gaps discussed here so that it fully
>     encompases the requirements so far described, for WG adoption.
> 
>     I'm sure I'm misinterpreting. What it sounds like you are saying is
>     "I want bierin6 to be adopted so let's fix the gaps so we can
>     begin". Since both solutions meet the requirements, I'm hoping you
>     meant "Let's fix the gaps in bierin6 so we can begin adoption calls
>     for both bierv6 and bierin6".
> 
>     mike
> 
> 
>     On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
> 
>      > Hi Gyan,
>      >
>      >
>      >
>      > Great that we reached consensus on BIERin6.
>      >
>      > Now there are two lingering points alluded to in this thread, but
>      > given it’s been such a long and deeply nested tread, I’ll start a new
>      > thread about it.
>      >
>      >
>      >
>      > Thanks.
>      >
>      > Jeffrey
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[e-mail]
>     <mailto:[e-mail]>>
>      > *Sent:* Monday, November 23, 2020 1:32 AM
>      > *To:* Jeffrey (Zhaohui) Zhang <[e-mail]
>     <mailto:[e-mail]>>
>      > *Cc:* Alvaro Retana <[e-mail]
>     <mailto:[e-mail]>>; BIER WG <[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>; Tony
>     Przygienda <
>      > [e-mail] <mailto:[e-mail]>>;
>     draft-ietf-bier-ipv6-requirements <
>      > [e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>      >
>      >
>      >
>      > *[External Email. Be cautious of content]*
>      >
>      >
>      >
>      > Hi Jeffrey
>      >
>      >
>      >
>      > That’s the last of my questions related to BIERin6.
>      >
>      >
>      >
>      > I thank you for taking the time to go over the BIERin6 draft in
>     detail.
>      >
>      >
>      >
>      > We have reached consensus as well as are in sync,  and I now have a
>      > better understanding of BIERin6.
>      >
>      >
>      >
>      > During the discussions I did mention that maybe in BIERin6 optional
>      > IPv6 tunneling should be removed, as it seemed to create some
>      > confusion, but now I am clear and as both the L2/tunnel and IPv6
>      > L3/tunnel encapsulation single hop or multi hop tunnel both have the
>      > clean BIER layering and complement each other I agree they belong
>     together in the same draft.
>      >
>      > Even though L2/tunnel exists today as part of RFC8296 it makes sense
>      > to be part of the overall BIERin6 solution.
>      >
>      >
>      >
>      > I am clear on the two IANA code points requests required for the
>      > optional
>      > IPV6 encapsulation option.
>      >
>      >
>      >
>      > Over the course of this thread we did touch on some technical reasons
>      > why
>      > IPV6 encapsulation is necessary which I you mentioned in some of your
>      > responses.
>      >
>      >
>      >
>      > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel
>      > option and BIERv6 are not transitional and are long term
>     solutions and
>      > there are reasons why that we can add to the requirements draft as to
>      > why IPV6 encapsulation is necessary below:
>      >
>      >
>      >
>      > - Operator requirement for IPV6 encapsulated packets  and not L2
>      > encapsulation.
>      >
>      > -FRR
>      >
>      >
>      >
>      > I think we are all set to start updating the Requirements draft.
>      >
>      >
>      >
>      > In-line Gyan6>
>      >
>      >
>      >
>      > Kind Regards
>      >
>      >
>      >
>      > Gyan
>      >
>      >
>      >
>      > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
>      > [e-mail] <mailto:[e-mail]>> wrote:
>      >
>      > Gyan,
>      >
>      >
>      >
>      > Please see zzh6> below.
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[e-mail]
>     <mailto:[e-mail]>>
>      > *Sent:* Sunday, November 22, 2020 9:49 PM
>      > *To:* Jeffrey (Zhaohui) Zhang <[e-mail]
>     <mailto:[e-mail]>>
>      > *Cc:* Alvaro Retana <[e-mail]
>     <mailto:[e-mail]>>; BIER WG <[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>; Tony
>     Przygienda <
>      > [e-mail] <mailto:[e-mail]>>;
>     draft-ietf-bier-ipv6-requirements <
>      > [e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>      >
>      >
>      >
>      > *[External Email. Be cautious of content]*
>      >
>      >
>      >
>      >
>      >
>      > Hi Jeffrey
>      >
>      >
>      >
>      > Agreed we have reached a consensus.
>      >
>      >
>      >
>      >
>      >
>      > Few more questions to iron out understanding.
>      >
>      >
>      >
>      > In line gyan4>
>      >
>      >
>      >
>      > Zzh6> Apparently there are still disconnects 😊
>      >
>      >  Gyan> Thank you for all the detailed responses.  We are in sync now!
>      >
>      > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
>      > [e-mail] <mailto:[e-mail]>> wrote:
>      >
>      > Hi Gyan,
>      >
>      >
>      >
>      > Yes I believe we’ve reached consensus.
>      >
>      >
>      >
>      > Please see zzh5> below about some details.
>      >
>      >
>      >
>      > *From:* Gyan Mishra <[e-mail]
>     <mailto:[e-mail]>>
>      > *Sent:* Sunday, November 22, 2020 4:19 PM
>      > *To:* Jeffrey (Zhaohui) Zhang <[e-mail]
>     <mailto:[e-mail]>>
>      > *Cc:* Alvaro Retana <[e-mail]
>     <mailto:[e-mail]>>; BIER WG <[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>; Tony
>     Przygienda <
>      > [e-mail] <mailto:[e-mail]>>;
>     draft-ietf-bier-ipv6-requirements <
>      > [e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>      >
>      >
>      >
>      > *[External Email. Be cautious of content]*
>      >
>      >
>      >
>      > Hi Jeffrey
>      >
>      >
>      >
>      > This has been a very informative exchange and extremely helpful for
>      > all of us to get onto the same page from a basic understanding POV.
>      >
>      >
>      >
>      > Much appreciated all your help and feedback helping clarify my
>     confusion.
>      >
>      >
>      >
>      > I am answering in-line but now connecting the dots how is in today’s
>      > RFC
>      > 8296 Non MPLS BIER Ethernet going to transport IPv6?
>      >
>      >
>      >
>      > From your answers below it cannot work as we need two IANA code point
>      > one for IPv6 next header type and ICMPv6.
>      >
>      >
>      >
>      > Zzh5> The existing model/concept works except that we need to two
>     code
>      > points if IPv6 tunneling is used for either getting over non-BFRs or
>      > for FRR. One may deem non-BFR as a short-term scenario but FRR
>     will be
>      > here for the long run.
>      >
>      >
>      >
>      >     Gyan4>I am a little confused here with the code points.  For
>      > BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether
>     type 0xAB37.
>      >
>      >
>      >
>      > Ethernet -0xAB37 l BIER | IPv6 | payload
>      >
>      >
>      >
>      > Zzh6> Note that IPv6 header is not needed – it should be Ethernet
>      > Zzh6> -0xAB37
>      > l BIER | payload. Of course, if SRv6 style VPN must be used, then
>     IPv6
>      > header may be inserted between BIER and payload, only for the SRv6
>      > style VPN purpose.
>      >
>      > Gyan> Understood
>      >
>      > Ethernet -0xAB37 l BIER l ICMPv6 | payload
>      >
>      >
>      >
>      > Zzh6> ICMP was mentioned not for encapsulation but for the following:
>      >
>      >  Gyan6>Understood
>      >
>      > Zzh6> 2.1.  IPv6 Options Considerations
>      >
>      >
>      >
>      >    For directly connected BIER routers, IPv6 Hop-by-Hop or
>     Destination
>      >
>      >    options are irrelevant and SHOULD NOT be inserted by BFIR on the
>      >
>      >    BIERin6 packet.  In this case IPv6 header, Next Header field
>     should
>      >
>      >    be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
>      >
>      >    multiple extension header where the last extension header has a
>      > Next
>      >
>      >    Header field set to TBD, SHOULD be discard and the node should
>      >
>      >    transmit an ICMP Parameter Problem message to the source of the
>      >
>      >    packet (BFIR) with an ICMP code value of TBD10 ('invalid options
>      > for
>      >
>      >    BIERin6').
>      >
>      >
>      >
>      > In this particular scenario where adjacent BFRs support Ethernet link
>      > layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation
>     and the
>      > need for the next header code point above is the packet format:
>      >
>      >
>      >
>      > Excerpt from RFC 8296
>      >
>      >
>      >
>      >    Therefore, if a non-MPLS BIER packet is encapsulated in an
>     Ethernet
>      >
>      >    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332
>      >
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo>
>      >
>     k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
>     <http://k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp>
>      > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
>      > defense.com
>     <http://defense.com>%2Fv3%2F__https%3A%2Ftools.ietf.org
>     <http://2Ftools.ietf.org>%2Fhtml%2Frfc5332__%3B!!
>      >
>     NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8
>      > 4ssHlj%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com
>     <http://40futurewei.com>%7C97b8a34
>      >
>     14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
>      >
>     C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>      >
>     oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8EiHsMns5Jut
>      > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=0>].  IEEE
>      >
>      >    has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
>      >
>      >
>      >
>      >
>      >
>      > In the case of BIERin6 optional encapsulation option, in case where
>      > operators requires packets forwarded in IPv6 or tunneling over
>     Non BFR
>      > packet format below:
>      >
>      >
>      >
>      > IPv6 outer header l BIER l Data
>      >
>      >
>      >
>      > So here the next header is BIER so corresponding next header code
>     point.
>      >
>      >
>      >
>      >
>      >
>      > So below is for both cases IANA code point allocation for “L2” next
>      > header where next header is IPv6 or ICMPV6, and then the optional
>     IPv6
>      > encapsulation option where the next header is BIER.
>      >
>      >
>      >
>      > Would those be two separate IANA code point requests I what I see
>     from
>      > the packet format.
>      >
>      >
>      >
>      > IANA L2 scenario:
>      >
>      > 2 code point requests for L2 for next header IPv6 and ICMP
>      >
>      >
>      >
>      > Zzh6> I don’t follow what you’re talking about. If BIER header
>     follows
>      > Zzh6> L2
>      > header directly, no new code point is needed. It’s just “Ethernet
>      > 0xAB37 | BIER | payload”.
>      >
>      >
>      >
>      >     Gyan6> Agreed.
>      >
>      >
>      >
>      > IANA optional IPv6 scenario:
>      >
>      > 1 code point request for IPv6 for next header BIER
>      >
>      >
>      >
>      > Zzh6> If IPv6 encapsulation is used, either on between directly
>      > Zzh6> connected
>      > BFRs or indirectly connected BFRs, a new “next header” code point is
>      > needed for BIER.
>      >
>      >  Gyan6>Understood
>      >
>      >
>      > 5
>      >
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$
>     <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-bier-bierin6-07*section-5__*3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH*24&amp;data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C97b8a3414dbe40bd528708d892e35223*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637420852351965804*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0*3D&amp;reserved=0__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$>
>      >.
>      > IANA Considerations
>      >
>      >
>      >
>      >
>      >
>      >    IANA is requested to assign a new "BIER" type for "Next Header" in
>      >
>      >    the "Assigned Internet Protocol Numbers" registry.
>      >
>      >
>      >
>      >    IANA is requested to assign a new "BIERin6" type for "invalid
>      >
>      >    options" in the "ICMP code value" registry.
>      >
>      >
>      >
>      >    IANA is requested to assign a new "BIER IPv6 transportation
>      > Sub-sub-
>      >
>      >    TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
>      >
>      >    Registry.
>      >
>      >
>      >
>      >    IANA is requested to set up a new "BIER IPv6 transportation
>      > Sub-sub-
>      >
>      >    sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation
>     sub-sub-TLV"
>      >
>      >    Registry.
>      >
>      >
>      >
>      >
>      >
>      > My point is that the IANA allocation is different as the next header
>      > is different for the L2 scenario where next header is IPv6 or ICMPV6,
>      > and IPv6 encapsulation scenario where the next header is BIER.
>      >
>      >
>      >
>      > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is
>      > Zzh6> used
>      > (assuming Ethernet is the L2).
>      >
>      >  Gyan>Understood
>      >
>      > Based on this point I am making could we just do a RFC8296 bis
>     version
>      > and add the IANA code points for IPv6 and ICMPv6.
>      >
>      >
>      >
>      > Zzh6> Given the confusion/contention that have happened in the last
>      > Zzh6> two
>      > years, it is much better to specifically have a spec dedicated to
>      > supporting BIER in IPv6.
>      >
>      >  Gyan6> I think now looking at it holistically speaking I can now see
>      > parity between the L2/tunnel and L3/tunnel both also having the clean
>      > layering.  So I can see why adding existing L2/tunnel to BIERin6 even
>      > though it already exists made sense to bundle into BIERin6 total
>      > solution
> 
>     Juniper Business Use Only
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]