Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

[Gyan Mishra <[e-mail]>]

See IPv6 Jumbo grams in IANA IPv6 parameters codepoint.

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

0xC2 11 0 00010 Jumbo Payload [RFC2675 <https://www.iana.org/go/rfc2675>]

On Thu, Jan 28, 2021 at 8:48 AM Gyan Mishra <[e-mail]> wrote:

> All,
>
> Huaimo has provided some valuable responses to scaling issues.  One point
> to note as far as scaling is that most all provider run Jumbo frames 9216
> MTU and IPv4 length is 16 bits which can support up to 65,535 size packet.
>
> IPv6 header natively supports a 16 bit header length which is the same as
> IPv4.
>
> RFC 2765 specifies a hbh options Jumbo payload option that carried a 32
> bit length field 65,536 and 4,294,967,295 octets in length. Packets with
> such long payloads are referred to as
>
>    "jumbograms".
>
>
> All router and switch vendors today support super jumbo which is payload
> length between 9000 and 65535 capping today at 9216.
>
> In the future as memory and buffer sizes increase in hardware fixed
> function ASIC FPGA or programmable NPU  for packet IO processing the sizes
> will eventually jump to 65535.  The next big step will be jumbo grams.  😀
>
> With SRv6 unlike SR-MPLS traditional MPLS based PTA cannot be leveraged
> such as RAVP-TE or mLDP, so the options for P2MP MDT is very limited and If
> you don’t want the source node overhead of IR or SR replication SID, you
> just have BIER as your only option.
>
> Operators love having options and this draft provisss a valuable option
> that does not require expensive upgraded to support BFR BIER.
>
> I support WG adoption as stated and as this draft is very promising for
> operators as an SRv6 “BIER alternative”.
>
> Thanks
>
> Gyan
>
> On Wed, Jan 27, 2021 at 9:13 PM Jeffrey (Zhaohui) Zhang <zzhang=
> [e-mail]> wrote:
>
>> Hi Huamo,
>>
>>
>>
>> “For a network with 4k nodes”, how large could a multicast tree be, and
>> with draft-chen, how do you encode that tree in packets? How many copies
>> would you send if each copy is only for a sub-tree?
>>
>>
>>
>> A large network can be divided into BIER sub-domains, each with a smaller
>> bitstring. If you use tunnel segmentation then you can have efficient
>> replication all the way through (though the segmentation points will have
>> per-tree state). If you don’t want to use segmentation, the ingress can
>> tunnel one copy to each sub-domain and inside each sub-domain you can have
>> efficient replication.
>>
>>
>>
>> Jeffrey
>>
>>
>>
>> *From:* Huaimo Chen <[e-mail]>
>> *Sent:* Tuesday, January 26, 2021 10:39 PM
>> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Jeffrey (Zhaohui)
>> Zhang <zzhang=[e-mail]>; Bidgoli, Hooman (Nokia -
>> CA/Ottawa) <[e-mail]>; Stig Venaas <[e-mail]>;
>> [e-mail]; 'Toerless Eckert' <[e-mail]>
>> *Subject:* Re: [pim] pim wg adoption call for
>> draft-chen-pim-srv6-p2mp-path-01
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Jeffrey,
>>
>>
>>
>>     Thanks for your further comments.
>>
>>     My responses are inline below with prefix [HC4].
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* Jeffrey (Zhaohui) Zhang <[e-mail]>
>> *Sent:* Monday, January 25, 2021 10:08 PM
>> *To:* Huaimo Chen <[e-mail]>; Jeffrey (Zhaohui) Zhang <
>> zzhang=[e-mail]>; Bidgoli, Hooman (Nokia -
>> CA/Ottawa) <[e-mail]>; Stig Venaas <[e-mail]>;
>> [e-mail] <[e-mail]>; 'Toerless Eckert' <[e-mail]>
>> *Subject:* RE: [pim] pim wg adoption call for
>> draft-chen-pim-srv6-p2mp-path-01
>>
>>
>>
>> Hi Huaimo,
>>
>>
>>
>> Let me pull two points to the top of this email.
>>
>>
>>
>>
>>
>> [HC3]: This is for the case where the overhead in a BIER-TE packet is 10k
>> bits
>>
>> when one BitString without any set is used. For the same overhead, how
>> many links
>>
>> can be encoded.
>>
>> Zzh3> BIER-TE won’t use 10k bits in the packet. It will use a finite
>> number of bits (e.g. 512 bits or  1024 bits) with multiple sets, just like
>> you break the entire tree into different sub-trees. The comparison is, say
>> with 1024 bits as encoding space, how many nodes/links can each solution
>> encode. I don’t see how draft-chen can do better.
>>
>> [HC4]: For a network with 4k nodes, there can be about 32k links and 64k
>> BitPositions.
>>
>> When we use 1024 bits with multiple sets in the packet header,
>>
>> the number of sets and the size of the set need to represent 64k
>> BitPositions,
>>
>> but 1024 bits contains a sub-tree that can be encoded in 1024 bits.
>>
>> If the size of the set is 64 bits, the number of sets needs to be 10 bits.
>>
>> Each set is encoded using 74 (64 bits for BitString + 10 bits for SI)
>> bits.
>>
>> 1024 bits can contain 1024/74 = 13 sets.
>>
>> For a sub-tree traversing 13 links with BitPositions in 13 sets,
>>
>> 1024 bits encodes 13 links of this sub-tree in BIER-TE.
>>
>> With a good SID compression, the size of compressed SID can be 21 bits
>>
>> (12 bits for node IDs, 3 bits for branches, 6 bits for number of SIDs),
>>
>> 1024 bits can encode 1024/21 = 48 links/nodes of a sub-tree in
>> draft-chen.
>>
>>
>>
>> [HC3]: It should be a new forwarding scheme for SRv6 replication segment.
>>
>> Under the network programming, replication SID is a new type of SID.
>>
>> It will have a new program/procedure for the behavior of this new SID
>>
>> even though it is “like” existing MPLS P2MP.
>>
>> Zzh3> The general SRv6 network programing idea is that an IPv6 address is
>> broken into the locator part and func/arg part. The locator part gets
>> traffic to a node and the func/argc part is looked up to decide what to do
>> next. SRv6-P2MP follows that perfectly, so **nothing is new**. When I
>> said it is “like” existing MPLS P2MP, I should also have said that it uses *
>> *existing** SRv6 mechanism.
>>
>> Zzh3> Jeffrey
>>
>>
>>
>> *From:* Huaimo Chen <[e-mail]>
>> *Sent:* Monday, January 25, 2021 11:45 AM
>> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Jeffrey (Zhaohui)
>> Zhang <zzhang=[e-mail]>; Bidgoli, Hooman (Nokia -
>> CA/Ottawa) <[e-mail]>; Stig Venaas <[e-mail]>;
>> [e-mail]; 'Toerless Eckert' <[e-mail]>
>> *Subject:* Re: [pim] pim wg adoption call for
>> draft-chen-pim-srv6-p2mp-path-01
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Jeffrey,
>>
>>
>>
>>     Thanks for your further comments.
>>
>>     My responses are inline below with prefix [HC3].
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>>
>>
>> ------------------------------
>>
>> *From:* Jeffrey (Zhaohui) Zhang <[e-mail]>
>> *Sent:* Sunday, January 24, 2021 11:26 PM
>> *To:* Huaimo Chen <[e-mail]>; Jeffrey (Zhaohui) Zhang <
>> zzhang=[e-mail]>; Bidgoli, Hooman (Nokia -
>> CA/Ottawa) <[e-mail]>; Stig Venaas <[e-mail]>;
>> [e-mail] <[e-mail]>; 'Toerless Eckert' <[e-mail]>
>> *Subject:* RE: [pim] pim wg adoption call for
>> draft-chen-pim-srv6-p2mp-path-01
>>
>>
>>
>> Hi Huaimo,
>>
>>
>>
>> Please see zzh2> below. I trimmed some text.
>>
>>
>>
>>
>>
>> Zzh> Plus the uSID-Block-ID, for each SRv6 SID that is needed? More below.
>>
>> [HC2]: The size of compressed SID (u bits) is the average size of
>>
>> a compressed SID. If compressing method uses uSID-Block-ID, it is
>> considered
>>
>> in the average size. There are a few of methods for compressing SIDs.
>>
>> They may have different compression rates.
>>
>>
>>
>> Zzh2> Before WG adoption, the draft needs to have details spelled out
>> with one of the compression methods. I don’t think it scales even w/
>> compression, but it’s a non-starter at all w/o compression.
>>
>> [HC3]: The details about one compression method is posted in one of my
>>
>> previous responses.
>>
>> I believe that it is scalable with compression. The details in the
>> example
>>
>> of one compression method illustrated, on average, one link on a multicast
>>
>> tree uses 32 bits. This can be improved to 20 bits per link.
>>
>> It can be a starter without compression in the following way.
>>
>> For a P2MP/multicast path/tree, the tree can be "split" into multiple
>> sub-trees
>>
>> such that each of the sub-trees can be encoded in the segment list of the
>>
>> finite size.
>>
>>
>>
>> Suppose that the size of SI and BitString are s and b bits respectively,
>> and
>>
>> the maximum number of possible BitPositions is M bits, the overhead of
>> BIER-TE
>>
>> is M bits if a maximum BitString is used,
>>
>> (in this case, M may greater than N*u. For example, when M = 10k, u = 40,
>>
>> M > N*u for N < 10k/40)
>>
>> up to N*(s+b) if bit sets are used.
>>
>> (in this case, N*(s+b) may greater than N*u. For example, when b = 64, s
>> = 10,
>>
>> u = 40, N*(s+b) > N*u )
>>
>>
>>
>> zzh> Do you mean “M = 10, 000”?
>>
>> [HC2]: This is an example value for M. For a network with 10k links,
>> there are 20k bitpositions.
>>
>> On average, the maximum bitposition is around 10k.
>>
>>
>>
>> zzh> The overhead consideration should be on a per-packet base. How much
>> of a sub-tree can you encode in **one** packet with a header of a
>> certain size? Your calculation does not seem be for that (and I have
>> trouble following it).
>>
>> [HC2]: With overhead M bits in a packet, M/u links can be encoded.
>>
>>
>>
>> Zzh2> I assume you won’t have 10k bits in a packet for encoding the
>> (sub-)tree, right? So the key is how many bits in one packet you can use
>> for encoding the (sub-)tree, and how many leaf/replication nodes you can
>> fit in.
>>
>> [HC3]: This is for the case where the overhead in a BIER-TE packet is 10k
>> bits
>>
>> when one BitString without any set is used. For the same overhead, how
>> many links
>>
>> can be encoded.
>>
>>
>>
>> Zzh> Additionally, the text seems to assume/imply that there is a
>> continuous block of uSIDs. But with 40-bit uSIDs, you can only put two
>> uSIDs in an SRv6 SID? How large would the segment list be if you want to
>> encode a reasonably sized sub-tree?
>>
>> [HC2]: "assume" is used to name a variable such as "assume" that
>>
>> the size of compressed SID is u bits. Here u is a variable for the
>>
>> the size of compressed SID on average. Some example values for the
>>
>> variables are given. There seems no imply.
>>
>> There are a few of methods for compressing SIDs. The method using uSIDs
>>
>> is one of them. The size of the segment list for a sub-tree is u*N bits,
>>
>> where N is the number of links on the sub-tree.
>>
>>
>>
>> Zzh2> How about putting some uSID details in the draft as I mentioned in
>> the other email?
>>
>> [HC3]: We will add some details in the draft.
>>
>>
>> 3. If this did not involve new forwarding scheme (i.e. new hardware) one
>> could argue that multiple solutions could be developed. But given that this
>> does need new hardware and does not do better than alternatives (e.g.
>> BIER-TE), why bother.
>>
>> [HC]: It seems that both SR-P2MP and BIER-TE are involved with new
>> forwarding schemes.
>>
>> Zzh2> SR-P2MP with MPLS does NOT involve new forwarding scheme at all.
>> It’s the same as existing mLDP/RSVP-TE P2MP in the forwarding plane. For
>> SRv6 replication segment, it’s also “like” existing MPLS P2MP in that part
>> of the IPv6 address is used as lookup key just like a label (and that is
>> not different from the SRv6 VPN).
>>
>> [HC3]: It should be a new forwarding scheme for SRv6 replication segment.
>>
>> Under the network programming, replication SID is a new type of SID.
>>
>> It will have a new program/procedure for the behavior of this new SID
>>
>> even though it is “like” existing MPLS P2MP.
>>
>> Zzh2> The scheme in draft-chen is so much different - it encodes a
>> sub-tree and forwarding is certainly more complicated. If it does scale
>> well, then  it is worth it even as a new forwarding scheme, but that has
>> not been concluded.
>>
>> [HC3]: Under the network programming, the behavior of the forwarding
>>
>> is a new program/procedure, which uses existing encap with the SIDs of a
>>
>> sub-tree. It seems not that complicated.
>>
>> Zzh2> BIER-TE is a new forwarding scheme, but it is by far the best
>> per-tunnel TE solution for multicast that does not have per-tunnel state
>> inside the network, and it went through due scrutiny. Draft-chen needs to
>> be scrutinized as well, and it needs to show that it does better to proceed
>> as yet another new forwarding scheme.
>>
>> [HC3]: Whether it is the best depends on a number of factors, some of
>> them
>>
>> are explained in previous responses.
>>
>> Zzh2> Jeffrey
>>
>> Zzh> Because of new forwarding schemes, BIER went through the process of
>> forming a new WG, and BIER-TE was originally on the experimental track.
>> More importantly, my earlier point is that the new scheme should scale
>> better (at least as well) for it to be worthy.
>>
>> [HC2]: The new forwarding scheme (or say forwarding behavior) in our
>> draft
>>
>> can be defined in a small program/procedure in the network programming.
>> This
>>
>> is very different from that in BIER, where a new WG is formed.
>>
>> We will update the draft to address your concerns and make it clearer.
>>
>> Your earlier point is responded in my previous response.
>>
>>
>>
>> Zzh> Jeffrey
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>>
>>
>> Juniper Business Use Only
>>
>> Juniper Business Use Only
>> _______________________________________________
>> pim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pim
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD