Indeed - I would not mind such clarification for the cases where the host originates packets without SRH.
In fact modifying packet header with no SRH present would mean additional state in the segment endpoints which is something SR architecture is trying to avoid. Regards, R. On Mon, Mar 25, 2024 at 6:06 PM Tom Herbert <t...@herbertland.com> wrote: > On Mon, Mar 25, 2024 at 10:04 AM Robert Raszuk <rob...@raszuk.net> wrote: > > > > Hi Tom, > > > > I don't think so, but I admit I may not be aware of some interesting use > cases .... > > Robert, > > Based on previous discussions, my understanding is that there was some > intent to allow this. Maybe it should be a clear MUST NOT in the draft > to resolve the issue. > > Tom > > > > > Many thx, > > R. > > > > > > On Mon, Mar 25, 2024 at 5:57 PM Tom Herbert <t...@herbertland.com> wrote: > >> > >> On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk <rob...@raszuk.net> > wrote: > >> > > >> > > >> > Actually looking at this from the perspective where SRH may be > omitted I see in the subject draft this clearly stated: > >> > > >> > A source node steers a packet into an SR Policy. If the SR Policy > results in a Segment List containing a single segment, and there is no need > to add information to the SRH flag or add TLV; the DA is set to the single > Segment List entry, and the SRH MAY be omitted.¶ > >> > > >> > > >> > That to me indicated that host computed checksum will be correct all > along the transit nodes. So no issue either here. > >> > > >> > Could someone illustrate with a drawing of packet's traversing the > network their assumed header format and forseen issues ? > >> > >> Robert, > >> > >> Are there any cases in segment routing where the Destination Address > >> is changed in flight and a routing header is not present in the > >> packet? > >> > >> Tom > >> > >> > > >> > Thx, > >> > R, > >> > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
