Hi Toerless, thanks for these questions and see below for responses:
> -----Original Message-----
> From: Toerless Eckert [mailto:t...@cs.fau.de]
> Sent: Tuesday, February 01, 2022 10:29 AM
> To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> Cc: Tom Herbert <t...@herbertland.com>; to...@strayalpha.com;
> int-area@ietf.org
> Subject: Re: [Int-area] IP parcels
>
> Fred,
>
> Section 5 of draft-templin-intarea-parcels-06 reads as if there is a mandatory
> dependency against draft-templin-6man-omni.
> Q1: Is that true ? If not, then i must be overlooking a description how
> parcels would work
> in the absence of OMNI.
IP parcels are packets that both set a non-zero IP {Total, Payload} Length
value and
also include a Jumbo Payload option. By RFC2675, this constitutes an illegal
jumbo
and so it is highly unlikely that any native links (let alone native paths)
would pass
the Parcel unless it was first encapsulated. So, encapsulation is required in
any case,
and OMNI encapsulation is the prime example given. But, it is possible that some
other form of encapsulation besides OMNI might pick up on the concept.
> Q2: If there is this dependency, how do you think the parcel draft could go to
> standard given how OMNI is individual submission.
I haven't really thought about that much yet but I don't think OMNI needs to be
a normative dependency; some other form of encapsulation might decide to
pick up on the parcel concept in the future.
> Q3: Is it possible for parcel support to only exist on an initial sequence of
> subnets, and as soon as a parcel packet has to be sent out to an interface
> that does not support parcels, the parcel is fragmented into
> normal/non-parcel
> IP packets ?
The parcel can only travel as far as the extent of the encapsulation, and once
the
encapsulation header is removed the only choices are: 1) deliver the parcel to
upper layers in the case of local delivery, 2) insert a new encapsulation header
(i.e., re-encapsulate) and forward the parcel further, or 3) unpack the parcel
and
forward each segment separately as an independent IP packet toward the final
destination.
I had not really thought about case 3), and I will have to drop back and
consider
whether that is something we would want to support. And, I think this only
applies
for the final leg of the path from the decapsulator to the final destination
and the
same logic cannot be applied for the initial leg of the path from an original
source
to a first encapsulating node.
What do you think?
Fred
> Thanks
> Toerless
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
