RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

[James Guichard <[e-mail]>]

Hi Tom,

Inline ..

-----Original Message-----
From: Tom Herbert <[e-mail]> 
Sent: Saturday, May 30, 2020 12:58 PM
To: James Guichard <[e-mail]>
Cc: Chengli (Cheng Li) <[e-mail]>; IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

On Sat, May 30, 2020 at 6:47 AM James Guichard <[e-mail]> wrote:
>
> Hi Tom,
>
> I do not expect this to be an issue as I would expect this type of state to be ephemeral by its very nature; if you reboot the router then it needs to advertise its capabilities - likewise other nodes should remove the previous state when they converge to see that the advertising node went down.

Jim,

Router advertisements are not instantaneous, there is a window of time that a legacy receiver will receive a packet with the new protocol because other nodes haven't gotten the information. How can the legacy receiver correctly process the RH in this case?

Jim> yes of course it is called convergence but .. if for some odd reason an operator does what you say and downgrades a node to remove G-SRH capability (not sure why they would do that but who knows) then they should also remove any policy that previously used the downgraded node as part of a source routed path. If you are going to remove a node regardless of whether it is G-SRH, SRH, CRH, then it stands to reason that you would have to remove and/or update any policy that included that node in a particular path, or have a backup path available. Further, in normal operation of any source routed solution you will need to make sure that packets end up at the right nodes as nasty things might happen if you don’t - this is actually especially bad with CRH as far as I can tell as if you send a packet to the wrong node and it happens to have a local identifier the same as the incoming packet its going to use that local CRH-FIB entry and send the packet to some IPv6 destination that was not the intended recipient.

This scenario isn't the only case that needs to be considered, there are also going to be other nodes that attempt to parse routing headers for various purposes that don't necessarily participate in the routing
protocol-- like firewalls, packet sniffers for debug, etc. How do you ensure backwards compatibility with these?

Jim> you don't need to as (1) they don’t support compression anyway or advertise capabilities in the IGP so will not be selected as part of a policy where compression is needed, and (2) if you have a mixed policy that includes non-compression capable nodes such as these then you address them as 128-bits (normal SID) and not 32-bit C-SID; note that one of the features of G-SRH is that you can carry different types of SIDs - normal 128-bit SIDs, C-SIDs, uSIDs, etc. 

The easiest answer to these questions is to just use a new routing type for compressed SIDs. This eliminates _any_ possibility of misinterpreting the header format. Either a node understands the new routing type or it doesn't, there's no ambiguity about that and it's little cost since there are plenty of routing type numbers available..

Tom

>
> Jim
>
> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Friday, May 29, 2020 7:12 PM
> To: James Guichard <[e-mail]>
> Cc: Chengli (Cheng Li) <[e-mail]>; IPv6 List <[e-mail]>; 
> Bob Hinden <[e-mail]>
> Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call 
> for "The IPv6 Compact Routing Header (CRH)")
>
> On Fri, May 29, 2020 at 3:13 PM James Guichard <[e-mail]> wrote:
> >
> > Hi Tom,
> >
> > I think section 8.2 answers this:
> >
> > 8.2.  Control Plane
> >
> >    REQ1-11: ISIS/OSPF/BGP-LS/PCEP extensions for advertising the
> >    capabilities of supporting G-SRv6 for SRv6 compression.
> >
> > So (1) a node has to indicate through capabilities advertisement that it is G-SRv6 compression capable, and (2) it must advertise a SID with "Continue of Compression (COC) behavior so that if it receives a packet using that SID then it knows to take 32-bits from the G-SID container rather than 128-bits (there is also an index carried as args for the SID so it knows where in the container the next C-SID can be found).
> >
> Jim,
>
> Suppose if a node advertises it is compression capable but at some point the administrator downgrades the software to no longer support compressed SIDs and reboots. When the node comes back what prevents other nodes from sending compressed SIDs to the node based on the fact the node previously advertised them but no longer does?
>
> Tom
>
>
>
> > Jim
> >
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Friday, May 29, 2020 5:53 PM
> > To: James Guichard <[e-mail]>
> > Cc: Chengli (Cheng Li) <[e-mail]>; IPv6 List <[e-mail]>; 
> > Bob Hinden <[e-mail]>
> > Subject: Re: Compatibility with SRH requirement (was Re: Adoption 
> > Call for "The IPv6 Compact Routing Header (CRH)")
> >
> > On Fri, May 29, 2020 at 2:31 PM James Guichard <[e-mail]> wrote:
> > >
> > > Hi Tom,
> > >
> > > If you look at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-cl-spring-generalized-srv6-for-cmpr-01.txt&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C565aa8197602409588ba08d804ba9459%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637264546716781903&amp;sdata=SmJyyh4elyj7rVqm9XoQeB%2Byvtg768oIMRq%2Fk3ELi9U%3D&amp;reserved=0 section 7 it says:
> > >
> > >       *  No control plane modification: Controller can install the SR
> > >          policy with 128-bits G-SID Containers, and the ingress treats
> > >          the G-SID Container as an opaque 128-bits SID without
> > >          understanding the structure of it.  G-SRv6 capable nodes
> > >          understand the COC flavor behaviors, while Compression disable
> > >          SRv6 nodes are unaware of Compression.
> > >
> > > Given this then I would say that the assumption is a non-compression capable node should not be selected as a segment within the G-SID container and therefore should never have to process a compressed SID within a received G-SRH. Of course, a non-compression capable node could still be part of the G-SRH as long as the segment it must process is of non-COC behavior.
> >
> > Jim,
> >
> > That would have to be more than an assumption, it would need to be a normative requirement like "a non-compression capable node MUST NOT be selected as a segment within the G-SID container". But then the question is how does the sender know which nodes are compression capable and which are non-compression capable"-- there is no concept of this distinction in RFC8754, so that information needs to come from an external source of the protocol definition, ie. configuration or negotiation. So that would mean that basic correctness of SRH protocol processing becomes dependent on the control plane.
> >
> > Tom
> >
> > >
> > > Jim
> > >
> > >
> > > -----Original Message-----
> > > From: ipv6 <[e-mail]> On Behalf Of Tom Herbert
> > > Sent: Friday, May 29, 2020 3:40 PM
> > > To: Chengli (Cheng Li) <[e-mail]>
> > > Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
> > > Subject: Compatibility with SRH requirement (was Re: Adoption Call 
> > > for "The IPv6 Compact Routing Header (CRH)")
> > >
> > > On Fri, May 29, 2020 at 2:18 AM Chengli (Cheng Li) <[e-mail]> wrote:
> > > >
> > > > Hi 6man,
> > > >
> > > > Since the first day CRH is proposed, it reminds me that we may need to address the overhead problem of SRv6 when SID list is long, that is great, thanks to Ron and others.
> > > >
> > > > But personally, I hope the solution should be compatible with SRv6 and SRH, which will simplify the issue and save a lot of works and time. Unfortunately, CRH is not.
> > >
> > > Cheng,
> > >
> > > I don't see how any solution for compressed SIDs can be compatible with SRH without employing a new routing type . Consider that one litmus test of compatibility is what happens when a legacy implementation receives a packet with the new protocol. To be compatible, the receiver must recognize that the protocol is unknown to it and not attempt to process it. If the receiver doesn't do that and processes the protocol anyway, then the results are non-deterministic and can actaully lead to harmful or insercure behavior (in other words it's not robust).
> > >
> > > So if legacy receiver receives a SRH header that contains 
> > > compressed SIDs that are less than 128 bits, it cannot correctly 
> > > process the packet. Someone might argue that this could be a 
> > > configuration option or SID length could be a negotiated 
> > > parameter, that doesn't work since
> > > RFC8754 has no provision for negotiating or configuring an 
> > > alternate SID length or format. RFC8754 is very clear on SID 
> > > length and the fact they are IPv6 addresses. From the draft: "Segment List[0..n]:
> > > 128-bit
> > > IPv6 addresses representing the nth segment in the Segment List.".
> > > So
> > > 128 bit SIDs are an invariant propery of the SRH routing type. The only way to change the SID length and be compatilble with SRH is to use a new routing type, which means that CRH _is_ compatible with SRH (an SRH receiver that receives a CRH RH won't attempt to process it).
> > >
> > > Tom
> > >
> > >
> > > > Truly, some people may jump up to say there is no requirement to be compatible with SRv6. I respect them and their POVs, but I also respect my POV.
> > > > I do not hope the IETF to spend a lot of time to build a brand new data plane and control plane, while some compatible solutions are there[1]. But people are free to develop a tech like that if they want.
> > > >
> > > > However, the development roadmap of CRH really shocked me.
> > > >         * At the beginning, SRv6+ was proposed, the data plane is CRH
> > > >         * them it became SRm6, the data plane is CRH.
> > > >         * SRm6 requested to be adopted in SPRING, and get the answer "too early".
> > > >         * In Feb, 2020, CRH removed the normative reference to SRm6, and stated to be replacement of RH0. In this way, CRH was stated to have no dependency on SRm6, while the data plane of SRm6 is CRH[2]. Amazing!
> > > >                 * In May 5th,  CRH asked for WG adoption in 6man, and get "Too early" again.
> > > >         * RH0 was removed after discussion in ML, and CRH get another base on general purpose of RH.
> > > >         * And several days later, a WG adoption poll is issued. Amazing+!
> > > >
> > > > Right now, I do not know where the requirements of CRH come from, and how CRH can get here.
> > > > At the beginning, the requirements of CRH may be:
> > > >       * Challenges from overhead of SRv6 when SID list is long( SID >5 )
> > > >       * IPv6 address needs to be ONLY the address of interface.
> > > > Regarding SRv6 overhead,
> > > > * If CRH aims to solve the SRv6 compression, there are some competing solutions there. They are starting from the requirement[3], architecture, but why CRH can jump to data plane adoption?
> > > > * If CRH does not aim to solve the SRv6 overhead, then what? It should be stated clear. And the work should follow the IETF progress of requirements-> use case->architecture->solution. The rules should be respected.
> > > > But I may be wrong, hidden rules may be somewhere that I don't know.
> > > >
> > > > Personally, I don't think the progress of CRH is a good case of progressing a work in IETF for young generation. Other people may follow the same direction to do something else again, and again.
> > > > Regarding IPv6 address, we have a lot of discussion on this. Will not repeat.
> > > >
> > > > >From the technology aspects, I do spend a lot of time to read the documents of SRm6, not only CRH, but including the CP extensions, VPN and SFC extensions, etc.
> > > > I may be wrong, but I think CRH is not that simple as some people stated.
> > > >
> > > > First of all, the below is my understanding of SRv6 and CRH based SRm6, again, I may be wrong.
> > > > * SRv6 uses one ID(128 bits address) to present
> > > >         * forwarding ID: 128 bits address
> > > >         * routing ID: 128 bits address
> > > >         * service ID: 128 bits address
> > > > * SRm6 use three IDs to present
> > > >         * forwarding ID: 128 bits address
> > > >         * routing ID:16/32 bits tag/CRID/?
> > > >         * service ID: option TLV in DOH Then
> > > > * When comparing TE Steering, SRv6 END/END.X is really simple, CRH I think it is the similar or the same. I don't see any more simplicities than SRH based SRv6.
> > > > * When a service instruction is added, SRv6 introduces a new ID value without introducing any new data plane encapsulation modifications. CRH based SRv6 introduce an option TLV in DOH with new data plane encapsulation modifications. I think adding an ID is simpler than a TLV, and more hardware friendly.
> > > > * When supporting SFC, SRv6 introduces some IDs, that is all, without new data plane encapsulation modifications. CRH does not support. CRH based SRm6 may support by using Options TLV in the first DOH[4] or NSH.
> > > >         * Option TLV in First DOH: The option in first DOH should apply to all the Segment endpoint. If configure different behavior to a same Option TLV, then the Option ID is like a Service Path ID, and per-flow/per SFC states are introduced back to all the nodes. SRm6 is still a source routing paradigm?
> > > >         * NSH:  too complicated to combination, per-flow/per-SFC states need to be maintained on all the nodes along the path.
> > > > * When supporting VPN, SRv6 introduces a new ID, without new data plane encapsulation modifications. SRm6 introduces a new TLV in DOH.
> > > > * When supporting FRR, I don't see the solution of CRH yet.
> > > > * When supporting OAM, do we need solution to support mapping table debugging? No idea.
> > > > * No reserved bits in CRH, I do not think the 32 bits are critical for hardware processing, but extensibilities are needed in almost protocol design. Less overhead does not mean best. I think this is a drawback of CRH instead of a advantage. But I may be wrong.
> > > > * In SRv6 or SR-MPLS, a SID is allocated by the node and processed by the node. Like an Adj SID in SR-MPLS and SRv6, the Adj Label and END.X SID are the value allocated by a node, and the forwarding ID is also ended at that node. But in CRH, the SID is allocated by the node, while the forwarding ID is allocated by the next segment endpoint, which is the interface address allocated by the next segment endpoint node, it looks very strange to me. But I may be wrong again!
> > > > * Flag, Tag, Last Entry provide more programmability to operators to support various services, they are features not overhead. Again, extensibilities is required and very important for a basic solution like a RH. Even for RH3 [5] in IOT.
> > > > * SRH TLV works like the DOH TLVs, so I think this is a alterative solution. But SID is the best option to specify a specific behavior on a specific node, rather than Option TLV with local configurations or container TLV design.
> > > >
> > > > Therefore, I really do not see the simplicity brought by CRH when CRH is used for supporting services.
> > > > It has the simplicity as SRH in TE. But has more complexities when supporting other services.
> > > > I prefer to comparing solutions in a service solution level instead of a peace of the whole solution, no meaning to me.
> > > >
> > > > Base on the above analysis, personally I don't think right now is the timing to adopt this document, so I do not support the adoption.
> > > >
> > > > Respect!
> > > > Cheng
> > > >
> > > >
> > > > [1].
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Fdraft-filsfilscheng-spring-srv6-srh-comp-sl-
> > > > en
> > > > c-
> > > > 01
> > > > &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e
> > > > 9a
> > > > 54
> > > > 04
> > > > 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> > > > 37
> > > > 26
> > > > 37
> > > > 80261923845&amp;sdata=DA4SX0kvjslMv48d6JBGbWk5rwY%2BGowA64MasmY6
> > > > RS
> > > > s%
> > > > 3D
> > > > &amp;reserved=0 [2].
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Fdraft-bonica-spring-sr-mapped-six-01%23secti
> > > > on
> > > > -6
> > > > &a
> > > > mp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a
> > > > 54
> > > > 04
> > > > 1c
> > > > 00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> > > > 26
> > > > 37
> > > > 80
> > > > 261923845&amp;sdata=9JDUZkDB9Wv8ahQ%2FSXzXnrMBJ33gArtla%2F6WbSYD
> > > > 09
> > > > M%
> > > > 3D
> > > > &amp;reserved=0 [3].
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Fdraft-cheng-spring-shorter-srv6-sid-requirem
> > > > en
> > > > t-
> > > > 01
> > > > &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e
> > > > 9a
> > > > 54
> > > > 04
> > > > 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> > > > 37
> > > > 26
> > > > 37
> > > > 80261923845&amp;sdata=DErYZazF4CUGR096chaqMHzNNp6Zhk15jSFB%2FOBP
> > > > oF
> > > > w%
> > > > 3D
> > > > &amp;reserved=0 [4].
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Fdraft-bonica-6man-seg-end-opt-07%23section-3
> > > > &a
> > > > mp
> > > > ;d
> > > > ata=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a5404
> > > > 1c
> > > > 00
> > > > 90
> > > > 8d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372637
> > > > 80
> > > > 26
> > > > 19
> > > > 23845&amp;sdata=lHiNW7wz%2Ffk0%2FWZ2cxs0Ahyp0f1%2BZ9tjjcsKUKz3J5
> > > > g%
> > > > 3D
> > > > &a
> > > > mp;reserved=0 [5].
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Frfc6554%23section-3&amp;data=02%7C01%7Cjames
> > > > .n
> > > > .g
> > > > ui
> > > > chard%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8
> > > > ff
> > > > 2a
> > > > 3b
> > > > 240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=trR
> > > > Pn
> > > > tk
> > > > M5
> > > > wNWfkgjNcY9hzwOajlM%2Feu%2F%2FAh3sr8ii0I%3D&amp;reserved=0
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: ipv6 [mailto:[e-mail]] On Behalf Of Bob 
> > > > Hinden
> > > > Sent: Saturday, May 16, 2020 6:14 AM
> > > > To: IPv6 List <[e-mail]>
> > > > Cc: Bob Hinden <[e-mail]>
> > > > Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
> > > >
> > > > This message starts a two-week 6MAN call on adopting:
> > > >
> > > >  Title:          The IPv6 Compact Routing Header (CRH)
> > > >  Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
> > > >  File Name:      draft-bonica-6man-comp-rtg-hdr-21
> > > >  Document date:  2020-05-14
> > > >
> > > >
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > to
> > > > ol
> > > > s.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr&amp;data=02%7
> > > > C0
> > > > 1%
> > > > 7C
> > > > james.n.guichard%40futurewei.com%7C055dd049e9a54041c00908d804082
> > > > 12
> > > > 9%
> > > > 7C
> > > > 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&am
> > > > p;
> > > > sd
> > > > at
> > > > a=uney8BmhjqknfjS%2FNEu1kpJFIUDM7RFniOO%2BT6n%2Ftvg%3D&amp;reser
> > > > ve
> > > > d=
> > > > 0
> > > >
> > > > as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.
> > > >
> > > > Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.
> > > >
> > > > This adoption call will end on 29 May 2020.
> > > >
> > > > The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.
> > > >
> > > > Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
> > > > to work on this.
> > > >
> > > > Regards,
> > > > Bob and Ole
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > -- IETF IPv6 working group mailing list [e-mail] 
> > > > Administrative
> > > > Requests:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.
> > > > gu
> > > > ic
> > > > ha
> > > > rd%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff2
> > > > a3
> > > > b2
> > > > 40
> > > > 189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=UyBGPL
> > > > 0e
> > > > hG
> > > > hH
> > > > 8Vr0DmFSo0nVZfHU22WmKxso60KXKRI%3D&amp;reserved=0
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > >
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [e-mail] 
> > > Administrative
> > > Requests:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.gu
> > > ic
> > > ha
> > > rd%40futurewei.com%7Cc8d0361197f14bd08e8008d8041aa900%7C0fee8ff2a3
> > > b2
> > > 40
> > > 189c753a1d5591fedc%7C1%7C1%7C637263859876104225&amp;sdata=y2AMOPkj
> > > zw
> > > R8
> > > gNj9Njp6%2BrMnEH45REr%2F6kX7OmsRPfE%3D&amp;reserved=0
> > > ------------------------------------------------------------------
> > > --