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

[Greg Shepherd <[e-mail]>]

I do not support adoption of this draft.

I agree with Jeffrey, Hooman, and Acee's concerns. Let me add my own.

The IETF, as a global standards body, should strive to standardize the
minimum set of necessary solutions to solve the issues at hand, not strive
to standardize every solution imagined for each issue. Otherwise our value
is reduced to chaff.

I had an early IETF Mentor (1990's) tell me that our primary
responsibility in the IETF is not just to come up with good ideas, but it
was to stop the bad ones. He went on to say bad ideas are like zombies;
they just keep coming back with new faces. This draft does not introduce
anything new or novel. Solutions like this have been proposed before.
Wrapping it in SR doesn't make it novel.

This isn't the first draft I've heard defended with "because SRv6" as some
silly justification. Sorry, but that is not a technical argument, and makes
no sense at all. Ethernet is ubiquitous, so should the IEEE just create
Ethernet extension headers to address every existing forwarding model? No,
they stay in their lane, add a next-proto pointer and pass it on. Can you
imagine the hardware manufactures' nightmares this would cause otherwise?
Not because it's technically challenging, but because the cost to support
every possible way of solving the same problem, because "Ethernet", would
be prohibitively expensive. As silly as this may sound, this is exactly
what is currently taking place with SRv6.

I am not suggesting SRv6 extension headers have no value, or are missguided
- far from it. It was my hope that the vision for SRv6 was an opportunity
to allow for rapid innovation in the forwarding plane where no current
solution existed. Or, if possible, create a better solution. But wrapping
an old idea in SRv6 doesn't make it novel. Even wrapping an existing
solution in SRv6 doesn't make it novel. On the contrary, it only undermines
the primary architecture that has been the model for the IETF for decades;
Layers.

And of all the layers we are charged to support in the IETF, the forwarding
plane, as I've been told from countless ADs, IAB members, etc, is rather
sacred. Any changes to the forwarding plane need to be carefully
scrutinized before being allowed to advance. I believe this same scrutiny
needs to be applied to every SRv6 forwarding extension proposed. You don't
get a pass simply by riding on top of SRv6. You are still modifying the
forwarding plane in ways that could eventually make the decades of work
from the IETF worthless. We need to strive for clarity, not confusion, and
our arguments need to remain honest, and technically focused.

- Shep

On Mon, Jan 25, 2021 at 5:59 AM Jeffrey (Zhaohui) Zhang <zzhang=
[e-mail]> wrote:

> Hi,
>
>
>
> I missed that you referred to “Generalized SRv6 Network Programming for
> SRv6 Compression”. If that’s what draft-chen is based on then draft-chen
> should be extended with relevant (vs. uSID) details, but then a related
> question is what is the status of that draft in the Spring WG, especially
> given the ongoing uSID work?
>
>
>
> Note that the above does not change the scaling property.
>
>
>
> Jeffrey
>
>
>
> *From:* pim <[e-mail]> *On Behalf Of * Jeffrey (Zhaohui) Zhang
> *Sent:* Sunday, January 24, 2021 11:04 PM
> *To:* Huaimo Chen <[e-mail]>; Stig Venaas <
> [e-mail]>; [e-mail]
> *Subject:* Re: [pim] pim wg adoption call for
> draft-chen-pim-srv6-p2mp-path-01
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Huaimo,
>
>
>
> The -01 revision is only based on the regular SRv6 SID, not uSID. In my
> earlier question, I was assuming uSID will be used and your example is also
> provided with uSID (I think). Even with uSID:
>
>
>
>    1. It takes two IPv6 addresses (256 bits) in SRH (with a 64-bit header
>    itself) in addition to the IPv6 header to encode the 4 leaves with 3
>    replication points in your example. If uSID is not used then it takes even
>    more bits. I am not convinced that is a scalable solution and I doubt that
>    I am alone.
>    2. The draft needs to be updated with uSID details. For example,
>    whether a uSID block ID is needed in each IPv6 address in the SRH, and
>    when/why padding is needed in the encoding. More questions will come after
>    the details are provided.
>
>
>
> Given this, I am even more convinced that that draft is not ready for
> adoption. It first needs to extended with uSID details and we still need to
> discuss the scaling property.
>
>
>
> Jeffrey
>
>
>
> *From:* Huaimo Chen <[e-mail]>
> *Sent:* Friday, January 22, 2021 5:10 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Stig Venaas <
> [e-mail]>; [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,
>
>
>
>     Thank you very much for your comments.
>
>     My responses are inline below with prefix [HC].
>
>     The figures for the DA and IPv6 header are attached in .txt file since
> their formats may be changed below for some email clients.
>
>     BTW, the previous emails with .PDF file could not go through PIM (held
> since it is too big).
>
>
>
> Best Regards,
>
> Huaimo
> ------------------------------
>
> *From:* pim <[e-mail]> on behalf of Jeffrey (Zhaohui) Zhang <
> zzhang=[e-mail]>
> *Sent:* Friday, January 22, 2021 8:53 AM
> *To:* wangyali <[e-mail]>; Stig Venaas <[e-mail]>;
> [e-mail] <[e-mail]>
> *Subject:* Re: [pim] pim wg adoption call for
> draft-chen-pim-srv6-p2mp-path-01
>
>
>
> I don't see a consensus on this yet on the mailing list.
>
> It would help if a specific illustration of SRv6 header with SRHs to
> encode the following tree of 4 leaves and 3 replication points (from the
> draft itself):
>
>                       [L1]                  R Ingress/Root
>                       /                    Li Egress/Leaf
>                      /                     Pi Transit Node
>                     /
>                   [P2]------[L2]
>                   /
>                  /
>                 /
>      [R]------[P1]                [L3]
>                 \                /
>                  \              /
>                   \            /
>                   [P3]------[P4]------[L4]
>
>             Figure 1: SR P2MP Path from R to L1, L2, L3 and L4
>
> In other words, translate <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m>
> into a real IPv6 header with multiple IPv6 addresses in the SRH (using the
> 40-bit uSID that Huaimo mentioned), and calculate the header size.
> [HC]: There are a few of methods for compressing SIDs.
>
> The following is the DA and IPv6 header using G-SRv6 compression method
>
> https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/__;!!NEt6yMaO-gk!TOoWyso7GdxJ13_OcGoZfz7dL0iJ01_zJUmMk9AicZQWhACefd4kuZWppq929ixx$>
>
> for <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m>.
>
> Node R sends a packet with the IPv6 header to the DA.
>
>
>
> Destination Address (DA):
>
>   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
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |         2001:db9:0:0 (Common Prefix)                          |
>
>  |                                                               |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            P1 ID              |       2       |       7       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |                                                               |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> IPv6 Header:
>
>   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
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  | Next Header   |  Hdr Ext Len  |  Routing Type | Segments Left |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Last Entry   |      Flags    |              Tag              |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            P4 ID              |       2       |       2       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            L3 ID              |       0       |       0       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            L4 ID              |       0       |       0       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |                            Padding                            |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            P2 ID              |       2       |       2       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            P3 ID              |       1       |       3       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            L1 ID              |       0       |       0       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |            L2 ID              |       0       |       0       |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> On average, the size u of a compressed SID is 32 bits in this case.
>
>
>
>
> Jeffrey
>
>
>
> 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
>