Subject: [Bier] BIER v6 requirements draft comments: draft-ietf-bier-ipv6-requirements ...

From: Antoni Przygienda <[email-masked]>
Date: Tue, 19 Nov 2019 05:50:50 +0000

Finally getting to fire off some comments on draft-ietf-bier-ipv6-requirements draft

3.4: I see NO requirements to do anything with SR or SRv6 in BIER WG charter so I am not sure how it ended up so prominently in the draft. And BIER is a hop-by-hop technology, it already includes provisions to transition non-BIER nodes via correct algorithms so not sure how SRv6 is of any use or relevance here. Of course BIER could be tunneled with SRv6 but then a BIER frame should be carried natively inside a SRv6 frame.  Comingling two level layer 2.5 transport technologies into a single layer format as the draft seems to imply is unnecessary and a bad idea since there will be resulting cross-talk.

4.2: completely disagreed. BIER is a hop-by-hop layer 2.5 technology. Modifying IP options is arguably far more expensive than next-protocol frame.

4.3:

     *   fragmentation will only play in IPv6 case if the frame is longer than IPv6 max frame size - BML roughly. No matter _where_ we stick the mask we face the same problem until we start to do BIER fragmentation and reassembly
     *   Again, SRv6 is neither in the charter nor an issue since BIER is a L2.5 hop-by-hop technology and not, as the authors want it, all of a sudden an implicit tunneling or multi-hop technology

4.11: and again BIER is hop-by-hop and it will rely on higher layers to re-assemble just like MPLS does.

I-D.xie-bier-ipv6-encapsulatio: yes, IPv6 architecture has the loophole for in flight modification of hop-by-hop header options but it does not mean it’s a good idea

Last, major objection is that by opening any IPv6 destination address to receive BIER frames from multiple hops away we are opening a completely security nightmare and argumenting that whole BIER layer has to be IPSEC’ed to close that hole is simply going into a seriously wrong direction IMO.

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Nov 2019 10:39:50 +0100

All,

I would tend to agree with Tony here. BIER is designed to construct optimal
replication trees with minimal state.

While there may be devices which do not support BIER IMHO the
right approach would be to use IGP forwarding adjaciencies across such
devices leaving BIER with no change and no such deep nesting like proposed
in this document. L2.5 can happily go over L2 :)

So what may be needed is to claim support for BIER over FAs + perhaps
define SR segments to be advertised as FAs in SPRING keeping both BIER and
its transport detached.

Best,
R.

wt., 19 lis 2019 o 06:51 Antoni Przygienda <prz=[email-masked]>
napisał(a):

> 3.4: I see NO requirements to do anything with SR or SRv6 in BIER WG
> charter so I am not sure how it ended up so prominently in the draft. And
> BIER is a hop-by-hop technology, it already includes provisions to
> transition non-BIER nodes via correct algorithms so not sure how SRv6 is of
> any use or relevance here. Of course BIER could be tunneled with SRv6 but
> then a BIER frame should be carried natively inside a SRv6 frame.  Comingling
> two level layer 2.5 transport technologies into a single layer format as
> the draft seems to imply is unnecessary and a bad idea since there will be
> resulting cross-talk.
>
> 4.2: completely disagreed. BIER is a hop-by-hop layer 2.5 technology.
> Modifying IP options is arguably far more expensive than next-protocol
> frame.
>
> 4.3:
>
>    - fragmentation will only play in IPv6 case if the frame is longer
>       than IPv6 max frame size - BML roughly. No matter _where_ we stick the mask
>       we face the same problem until we start to do BIER fragmentation and
>       reassembly
>       - Again, SRv6 is neither in the charter nor an issue since BIER is
>       a L2.5 hop-by-hop technology and not, as the authors want it, all of a
>       sudden an implicit tunneling or multi-hop technology
>
> I-D.xie-bier-ipv6-encapsulatio: yes, IPv6 architecture has the loophole
> for in flight modification of hop-by-hop header options but it does not
> mean it’s a good idea
>
>
>
> Last, major objection is that by opening any IPv6 destination address to
> receive BIER frames from multiple hops away we are opening a completely
> security nightmare and argumenting that whole BIER layer has to be IPSEC’ed
> to close that hole is simply going into a seriously wrong direction IMO.
>
>
>
> --- tony
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Mike McBride <[email-masked]>
Date: Tue, 19 Nov 2019 04:57:43 -0800

Hi Tony,

> Finally getting to fire off some comments on draft-ietf-bier-ipv6-requirements draft

MM: Yay! thank you, happy we are getting some feedback.

> 3.4: I see NO requirements to do anything with SR or SRv6 in BIER WG charter so I am not sure how it ended up so prominently in the draft. And BIER is a hop-by-hop technology, it already includes p…

MM: Unless my co-authors, or anyone else, disagrees, I say we simply
remove this section and any and all references to SRv6 if it's not
helpful. Focus should be on IPv6 related requirements.

> 4.2: completely disagreed. BIER is a hop-by-hop layer 2.5 technology. Modifying IP options is arguably far more expensive than next-protocol frame.

MM: You completely disagree with requirement 4.2? You believe that the
solution _should_ require hop-by-hop modification of the IP source
address field? Or just disagree with our explanation of it? This
requirement came from Eric Rosen long ago. Please suggest new
requirement wording that makes you happy.

> 4.3:
>
> fragmentation will only play in IPv6 case if the frame is longer than IPv6 max frame size - BML roughly. No matter _where_ we stick the mask we face the same problem until we start to do BIER fragmentation and reassembly

MM: So the requirement "should not require the BFRs to inspect layer 4
or require any changes to layer 4." is fine but you don't like the
fragmentation wording? Or do you not like the requirement period? We
can certainly re-word it or remove it if it causes heartache. Again
this was another Rosen requirement I believe. Fragmentation is
optional for BIER, but, from an IPv6 point of view, it is a basic
capability and we figured we should support it. Maybe we don't but
let's get the requirement down.

> Again, SRv6 is neither in the charter nor an issue since BIER is a L2.5 hop-by-hop technology and not, as the authors want it, all of a sudden an implicit tunneling or multi-hop technology

MM: Consider SRv6 gone from this draft since having it in there is
causing pain.

> 4.11: and again BIER is hop-by-hop and it will rely on higher layers to re-assemble just like MPLS does.

MM: and again IPv6 does provide the fragmentation/assembly capability,
so we figured BIER should inherit such capability but we could
certainly be wrong. Are you in favor then of removing the 4.11
requirement involving fragmentation? Or re-wording it?

> I-D.xie-bier-ipv6-encapsulatio: yes, IPv6 architecture has the loophole for in flight modification of hop-by-hop header options but it does not mean it’s a good idea

MM: This isn't a solutions document so whether it's a good idea or not
can be saved for that document to justify. We will move the solutions
overviews to an appendix.

> Last, major objection is that by opening any IPv6 destination address to receive BIER frames from multiple hops away we are opening a completely security nightmare and argumenting that whole BIER l…

MM: Which requirement are you referring to? Perhaps you are referring
to requirement 4.3 involving L4 Inspection where we mention IPsec? We
figured the IPSEC architecture should be inherited from IPv6 if we are
considering BIER in IPv6 but it looks like you don't agree. We are
happy to modify/add/remove any requirement just needs specifics.

thanks,
mike

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 19 Nov 2019 21:46:36 +0000

Please see inline,

> helpful. Focus should be on IPv6 related requirements.

Agreed. 

> overviews to an appendix.

Indeed. that helps to keep the focus on requirements. 

> MM: Which requirement are you referring to?

Perhaps, requirement 4.2 - DA modification !!!

If we continue with BIER being an L2.5 forwarding technology in IPv6 paradigm, then modifying v6 DA yields limited to no value. And tunneling would be the only sane way to accommodate non-BIER transit routers, if any. 

However, this means IPv6 being treated in a similar manner as IPv4. Just a payload. This should be debated.  

Cheers,
Rajiv  

> On Nov 19, 2019, at 8:57 PM, Mike McBride <[email-masked]> wrote:
> 
> Hi Tony,
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 Nov 2019 10:01:50 +0000

Hi all,

Thank you all for raising your concerns on the list and on the ietf106 mic. 
Have talked to you guys more after the session, and watched the video more, and I find I have understand your concerns. 
I'd like to continue this debating now, to avoid forgetting anything and avoid the discussion freezing.

The raised questions include, the L2.5 and L3, TTL, OAM, security. Req 4.2, 4.3 and 4.11, and so on.

I summarized as that, all the concerns come from the fact that, 12 requirements in the v6-requirements draft are target the IPv6 L3 BIER, and it can be shortened into one requirement: Requiring L3 BIER based on IPv6 !

And then, all the above concerns comes from the "L3 BIER" requirement, summarized as below:
1.Do we need it ? 
2.Does it breaks BIER architecture? 
3.Does it brings more security problems when deploying ? 
4.How should the solutions be, such as TTL/OAM /Multicast or unicast DA used/Multicast or unicast SA used/etc.

So maybe we can get this debating started on the first concern, Do we need it ? why do we need it ? why other solutions like L2.5/L4+ don't satisfy that?

I'd like to list my initial thoughts that, we really need a L3 BIER, for ease of BIER deployment in IPv6 network, within a larger BIER domain (which is beyond the normal BIER domain which is normally an IGP domain or IGP area/level), and leverages the reachability of IPv6 unicast address.

Your thoughts?

Best Regards,
Jingrong

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Wednesday, November 20, 2019 5:47 AM
To: Mike McBride <[email-masked]>
Cc: [email-masked]; Antoni Przygienda <prz=[email-masked]>
Subject: Re: [Bier] BIER v6 requirements draft comments: draft-ietf-bier-ipv6-requirements ...

Please see inline,

Agreed. 

Cheers,
Rajiv  

>> fragmentation will only play in IPv6 case if the frame is longer than 
>> IPv6 max frame size - BML roughly. No matter _where_ we stick the 
>> mask we face the same problem until we start to do BIER fragmentation 
>> and reassembly
> 
>> Again, SRv6 is neither in the charter nor an issue since BIER is a 
>> L2.5 hop-by-hop technology and not, as the authors want it, all of a 
>> I-D.xie-bier-ipv6-encapsulatio: yes, IPv6 architecture has the 
>> loophole for in flight modification of hop-by-hop header options but 
>> it does not mean it’s a good idea
>