Re: [Bier] comments for draft-zhang-bier-bierin6-04.txt

[[e-mail]]

Hi Toerless,






Thank you very much for your detailed comments! :-)


Very glad that more and more people are interested in BIERin6 work. 


We will discuss it and reply to you carefully.


Thank you again for your help! :-)






Best regards,


Sandy







原始邮件



发件人：ToerlessEckert <[e-mail]>
收件人：[e-mail] <[e-mail]>;
日 期 ：2020年03月12日 12:24
主 题 ：[Bier] comments for draft-zhang-bier-bierin6-04.txt


Comments on subject document inline. Thanks a lot for the work.

> 
> 
> 
> 
> BIER                                                            Z. Zhang
> Internet-Draft                                           ZTE Corporation
> Intended status: Standards Track                           A. Przygienda
> Expires: July 11, 2020                            Juniper Networks, Inc.
>                                                              I. Wijnands
>                                                            Cisco Systems
>                                                               H. Bidgoli
>                                                                    Nokia
>                                                               M. McBride
>                                                                Futurewei
>                                                          January 8, 2020
> 
> 
>                          BIER in IPv6 (BIERin6)
>                       draft-zhang-bier-bierin6-04
> 
> Abstract
> 
>    BIER is a new architecture for the forwarding of multicast data
>    packets.  This document defines native IPv6 encapsulation for BIER
>    hop-by-hop forwarding or BIERin6 for short.

Would suggest to change to something that does not say "native", because
the option described in this document of using ethernet-nonMPLS-BIER-IPv6 
encapsulation might not be seen as "native IPv6 encap" by IPv6
purists.

Propose:

"This document defines encapsulation hop-by-hop BIER forwarding for
IPv6, non-MPLS networks called BIERin6."

> Requirements Language
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC2119.
> 
> Status of This Memo
> 
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on July 11, 2020.
> 
> 
> 
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 1]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
> Copyright Notice
> 
>    Copyright (c) 2020 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (https://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  IPv6 Header . . . . . . . . . . . . . . . . . . . . . . . . .   3
>      2.1.  IPv6 Options Considerations . . . . . . . . . . . . . . .   3
>    3.  BIER Header . . . . . . . . . . . . . . . . . . . . . . . . .   4
>    4.  IPv6 Encapsulation Advertisement  . . . . . . . . . . . . . .   4
>      4.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   4
>      4.2.  Inter-area prefix redistribution  . . . . . . . . . . . .   5
>    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
>    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
>    7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
>    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
>      8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
>      8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
> 
> 1.  Introduction
> 
>    BIER [RFC8279] is a new architecture for the forwarding of multicast
>    data packets.  It provides optimal forwarding through a "multicast
>    domain" and it does not necessarily precondition construction of a
>    multicast distribution tree, nor does it require intermediate nodes
>    to maintain any per-flow state.
> 
>    This document specifies non-MPLS BIER forwarding in an IPv6 [RFC8200]
>    environment, refferred to as BIERin6, using non-MPLS BIER
>    encapsulation specified in [RFC8296].

This version of the sentence could also go into the abstract ;-)

>    MPLS BIER forwarding in IPv6 is outside the scope of this document.
> 
>    This document uses terminology defined in [RFC8279] and [RFC8296].
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 2]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
>    [RFC8296] defines the BIER encapsulation format in MPLS and non-MPLS
>    environment.  In case of non-MPLS environment, a BIER packet is the
>    payload of an "outer" encapsulation, which has a "next protocol"
>    codepoint that is set to a value that means "non-MPLS BIER".
> 
>    That can be used as is in a pure IPv6 non-mpls environment.  Between
>    two directly connected BFRs, a BIER header could directly follow link
>    layer header, e.g., an Ethernet header (with the Ethertype set to
>    0xAB37).  If a BFR needs to tunnel BIER packets to another BFR, e.g.
     ^^^^^^^^

Please add reference "according to RFC8296 section 2.2.3.

>    per [RFC8279] Section 6.9,

It would be worth IMHO to describe here that section RFC8279 6.9 describes
mechanisms to support partial BIER deployment by automatically calculating
non-adjacent downstream BFR and then uses tunneling to them to hop
over the non-BIER capable routers.

>    IPv6 encapsulation can be used, with the
>    destination address being the downstream BFR and the Next Header
>    field set to a to-be-assigned value for "non-MPLS BIER".

Would be clearer to state that RFC8279 does not prescribe an IPv6
next header type to encapsulate BIER into IPv6, but that this document
does this and uses the name "non-MPLS BIER" for it.

Also RFC8296 already uses the term "non-MPLS BIER" for Ethertype
0xAB37, so it would be an overload (*gasp* ;-) of that term to
also use it for a TBD IPv6 Next Header codepoint. Maybe come up with
another name for the TBD codepoint or use "non-MPLS BIER Ethertype"
vs. "non-MPLS BIER IPv6 NH".

>    The IPv6 encapsulation could be used even between two directly
>    connected BFRs in the following two cases:
> 
>    o  An operator mandates all traffic to be carried in IPv6.

An example (like on belows point) would help to motivate this.

IPv6-only forwarding plane features such as monitoring or filtering come to mind.

>    o  A BFR does not have BIER support in its "fast forwarding path" and
>       relies on "slow/software forwarding path", e.g. in environments
>       like [RFC7368] where high throughput multicast forwarding
>       performance is not critical.
> 
> 2.  IPv6 Header
> 
>    Whenever IPv6 encapsulation is used for BIER forwarding, The Next
>    Header field in the IPv6 Header (if there are no extension headers),
>    or the Next Header field in the last extension header is set to TBD,
>    indicating that the payload is a BIER packet.

Maybe use numbered TBD (TBD1) and introduce that TBD1 above where you first
talk about it.

>    If the neighbor is directly connected, The destination address in
>    IPv6 header SHOULD be the neighbor's link-local address on this
>    router's outgoing interface, the source destination address SHOULD be
>    this router's link-local address on the outgoing interface, and the
>    IPv6 TTL MUST be set to 1.

I've started a thread on 6man/6ops re. link-local-tunnel traffic as i
have the same also in my ANIMA draft, and in implementations i have
seen quite some issues tunneling traffic HW accelerated across IPv6 
link-local addresses and TTL=1.

Would welcome implementers in BIER to chime in if they would see this
as an issue.

If folks feel supporting this HW accelerated might be more complicated
than non-link-local tunnels, then it might be useful to change the
text to also allow/require support for using the BFR address even for
subnet adjacent BFR. In that case one would not use HL=1, and that
too i have seen to be a problem in HW accelerated forwarding plane:
HL/TTL=1 -> MUST punt (software processing).

>    Otherwise, the destination address SHOULD
>    be the BIER prefix of the BFR neighbor, the source address SHOULD be
>    this router's BIER prefix, and the TTL MUST be large enough to get
>    the packet to the BFR neighbor.

(Hop-limit, not TTL, MLD, not IGMP, everything gets better by new names ;-).

>    The Flow-ID in the IPv6 packet SHOULD be copied from the entropy
>    field in the BIER encapsulation.
> 
> 2.1.  IPv6 Options Considerations
> 
>    RFC 8200 section 4, defines the IPv6 extension headers.  Currently
>    there are two defined extension headers, Hop-by-Hop and Destination
>    options header, which can carry a variable number of options.  These

draft-ietf-6man-segment-routing-header is Routing Header, not Hop-by-Hop or Destination.

>    extension headers are inserted by the source node.
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 3]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
>    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').
> 
>    This also indicates that for disjoint BIER routers using IPv6

disjoint == Non subnet-adjacent ?

>    encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination
>    options be present in a BIERin6 packet.

This is a bit confusing, first you write what seems to only apply to
adjacent BFR, then in the next paragraph you seem to expand it to 
non-adjacent BFR. Maybe rewrite so it says you do not like hop-by-hop
options and destination options whether the BFR are adjacent or not ?

Don't have a strong opinion content wise. In general,
this is kinda safe and may make implementations easier, and can always
be superceeded by anothre RFC when there is an interesting option
in he future we would like to use with this encap. On the other hand, if/when
there is such an option header, there MUST be another RFC to make it
applicable to this RFC (by overriding it).

>    In this case, if additional
>    traffic engineering is required, IPv6 tunneling (i.e.  BIERin6 over
>    SRv6) can be implemented.

Given how the model described in this draft (source address is the sending BFR, not
the BFIR), is really end-to-end BIER (not end-to-end IPv6), i think 
each (adjacent, non-adjacent) BIER-hops IPv6 encapsulation is indeed IPv6
tunneling, so it is confusing/incorrect to use the term "IPv6 tunneling"
here only in the context of SRv6.

I would propose to improve the text to introduce the notion of "IPv6 tunneling"
earlier and explain at the point earlier where you start to dsicuss
option headers, that routing-headers are fine. 

If you want to use a much longer used form of IPv6 routing header than
SRv6 SRH, use the RPL Source Routing Header (RFC6554). Its also much more
widely deployed (millions of routers)

> 3.  BIER Header
> 
>    The BIER header MUST be encoded per Section 4.2 of [RFC8296].
> 
>    The BIFT-id is either encoded per
>    [I-D.ietf-bier-non-mpls-bift-encoding] or per advertised by BFRs, as
>    specificed in [I-D.dhanaraj-bier-lsr-ethernet-extensions].
> 
> 4.  IPv6 Encapsulation Advertisement

Seems like it would help to restructure 2,3 under forwarding plane and 4
a=under control/routing-plane sections ?

Also: Didn't i remember something from Alia saying that future control plane
work should be done in LSR ? I may be wrong. Just wondering if this section
can still be in this draft. Would make life easier, but we're still IETF.. ;-)

>    When IPv6 encapsulation is not required between directly connected
>    BFRs, no signaling in addition to that specified in
>    [I-D.dhanaraj-bier-lsr-ethernet-extensions] is needed.
> 
>    Otherwise, a node that requires IPv6 encapsualtion MUST advertise the
>    BIER IPv6 transportation sub-TLV/sub-sub-TLV according to local
>    configuration or policy in the BIER domain to request other BFRs to
>    always use IPv6 encapsulation.
> 
>    In presence of multiple encapsulation possibilities hop-by-hop it is
>    a matter of local policy which encapsulation is imposed and the
>    receiving router MUST accept all encapsulations that it advertised.
> 
> 4.1.  Format
> 
>    The BIER IPv6 transportation is a new sub-TLV of BIER defined in OSPF
>    [RFC8444], and a new sub-sub-TLV of BIER Info sub-TLV defined in ISIS
>    [RFC8401].
> 
> 
> 
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 4]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |    Type       |   Length      |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    o  Type: For OSPF, value TBD1 (prefer 12) is used to indicate it is
>       the IPv6 transportation sub-TLV.  For ISIS, value TBD2 (prefer 3)
>       is used to indicate it is the IPv6 transportation sub-sub-TLV.
> 
>    o  Length: 0.

Not quite sure about the policies (others in the WG will know better):
Should this document be "Updates" to those two RFCs ?

If i where to implement ISIS/OSPF for BIER (or troubleshoot it on the wirese,
write wireshark modules, etc. pp), marking this document an
update would help to find it, but technically, this is just an extension,
not changing anything, so i am not sure if it even can be an update.

The other point is whether or not to distinguish if link-local or
BFR address are supported for IPv6 encapsulation. Given my past pain
with IPv6 link-local HW support, i would certainly like to see
the ability to announce what amounts to "this node can only encap/decap
for its BFR address, but not link-local - but please send me also
to that address if you're subnet adjacent".

> 4.2.  Inter-area prefix redistribution
> 
>    When BFR-prefixes are advertised across IGP areas per
>    [I-D.dhanaraj-bier-lsr-ethernet-extensions] or redistributed across
>    protocol boundaries per [I-D.zwzw-bier-prefix-redistribute], the BIER
>    IPv6 transportation sub-TLV or sub-sub-TLV MAY be re-advertised/re-
>    distributed as well.

Ok, what is missing up to here is an upfront explanation that this draft is 
end-to-end (BFIR to BFER) BIER with hop-by-hop L2 encap and/or
IPv6 tunnels. And discuss the implications. For example, you will not
get ICMP error messages all the way back to the BFIR as you would get
in a model where forwarding was hop-by-hop IPv6 (plus BIER). I have
no opinions how relevant this is, but today if an SP does end-to-end
IPv6, then he would get forwarding errors back to the encap router in
his network (assuiming that customer traffic is IPv6 encapsulated there).
Likewise, there is no end-to-end PMTUD from IPv6 supported in this model

(which i think is stupid anyhow for multicast, so i am not saying this
 as an argument against this method, just to make sure that users coming
 from IPv6 understand all the implications).

> 5.  IANA Considerations
> 
>    IANA is requested to assign a new "BIER" type for "Next Header" in
>    the "Assigned Internet Protocol Numbers" registry.

BIERin6 ?

>    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-TLV"
>    type in the "OSPFv2 Extended Prefix TLV Sub-TLVs" Registry.

I would prefer "tunnel" instead of transport given how a new IPv6
header is added.

>    IANA is requested to set up a new "BIER IPv6 transportation Sub-sub-
>    TLV" type in the "IS-IS BIER Info sub-TLV" Registry.

same here.

> 6.  Security Considerations
> 
>    General IPv6 and BIER security considerations apply.

I am sure someone will have more security consideration ideas, but not me, not today . ;-)

> 7.  Acknowledgement
> 
>    The authors would like to thank Jeffrey Zhang for his review and
>    valuable contributions.
> 
> 8.  References
> 

Thanks a lot for the document

Toerless
> 
> 
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 5]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
> 8.1.  Normative References
> 
>    [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>               (IPv6) Specification", STD 86, RFC 8200,
>               DOI 10.17487/RFC8200, July 2017,
>               <https://www.rfc-editor.org/info/rfc8200>.
> 
>    [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
>               Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
>               Explicit Replication (BIER)", RFC 8279,
>               DOI 10.17487/RFC8279, November 2017,
>               <https://www.rfc-editor.org/info/rfc8279>.
> 
>    [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
>               Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
>               for Bit Index Explicit Replication (BIER) in MPLS and Non-
>               MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
>               2018, <https://www.rfc-editor.org/info/rfc8296>.
> 
>    [RFC8401]  Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
>               Zhang, "Bit Index Explicit Replication (BIER) Support via
>               IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
>               <https://www.rfc-editor.org/info/rfc8401>.
> 
>    [RFC8444]  Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
>               Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
>               Extensions for Bit Index Explicit Replication (BIER)",
>               RFC 8444, DOI 10.17487/RFC8444, November 2018,
>               <https://www.rfc-editor.org/info/rfc8444>.
> 
> 8.2.  Informative References
> 
>    [I-D.dhanaraj-bier-lsr-ethernet-extensions]
>               Dhanaraj, S., Wijnands, I., Psenak, P., Zhang, Z., Yan,
>               G., and J. Xie, "LSR Extensions for BIER over Ethernet",
>               draft-dhanaraj-bier-lsr-ethernet-extensions-00 (work in
>               progress), January 2019.
> 
>    [I-D.ietf-bier-bar-ipa]
>               Zhang, Z., Przygienda, T., Dolganow, A., Bidgoli, H.,
>               Wijnands, I., and A. Gulko, "BIER Underlay Path
>               Calculation Algorithm and Constraints", draft-ietf-bier-
>               bar-ipa-06 (work in progress), November 2019.
> 
>    [I-D.ietf-bier-idr-extensions]
>               Xu, X., Chen, M., Patel, K., Wijnands, I., and T.
>               Przygienda, "BGP Extensions for BIER", draft-ietf-bier-
>               idr-extensions-07 (work in progress), September 2019.
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 6]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
>    [I-D.ietf-bier-non-mpls-bift-encoding]
>               Wijnands, I., Xu, X., and H. Bidgoli, "An Optional
>               Encoding of the BIFT-id Field in the non-MPLS BIER
>               Encapsulation", draft-ietf-bier-non-mpls-bift-encoding-02
>               (work in progress), August 2019.
> 
>    [I-D.zhang-bier-babel-extensions]
>               Zhang, Z. and T. Przygienda, "BIER in BABEL", draft-zhang-
>               bier-babel-extensions-02 (work in progress), November
>               2019.
> 
>    [I-D.zwzw-bier-prefix-redistribute]
>               Zhang, Z., Bo, W., Zhang, Z., and I. Wijnands, "BIER
>               Prefix Redistribute", draft-zwzw-bier-prefix-
>               redistribute-03 (work in progress), September 2019.
> 
>    [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
>               Weil, "IPv6 Home Networking Architecture Principles",
>               RFC 7368, DOI 10.17487/RFC7368, October 2014,
>               <https://www.rfc-editor.org/info/rfc7368>.
> 
> Authors' Addresses
> 
>    Zheng(Sandy) Zhang
>    ZTE Corporation
> 
>    EMail: [e-mail]
> 
> 
>    Tony Przygienda
>    Juniper Networks, Inc.
> 
>    EMail: [e-mail]
> 
> 
>    IJsbrand Wijnands
>    Cisco Systems
> 
>    EMail: [e-mail]
> 
> 
>    Hooman Bidgoli
>    Nokia
> 
>    EMail: [e-mail]
> 
> 
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 7]
> 
> Internet-Draft                   BIERv6                     January 2020
> 
> 
>    Mike McBride
>    Futurewei
> 
>    EMail: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Zhang, et al.             Expires July 11, 2020                 [Page 8]

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