Hi Tom, I totally understand your point. But RFC8200 doesn't single out the source as the only node that can do this type of manipulation. "Any node along a packet's delivery path" is rather open to interpretation.
Arashmid -----Original Message----- From: Tom Herbert [mailto:t...@quantonium.net] Sent: 27 March 2018 15:50 To: Arashmid Akhavain <arashmid.akhav...@huawei.com> Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 On Tue, Mar 27, 2018 at 11:37 AM, Arashmid Akhavain <arashmid.akhav...@huawei.com> wrote: > Although segment end points are nodes along packets' delivery path, they are > terminating a segment. > So why is it considered a RFC8200 violation if SRH manipulation is restricted > to those nodes. > Hi Arashmid, Because only the source of a packet is allowed to create extension headers. The source is identified by the source address, and we know that intermediate nodes in segment routing are not the source since they don't change to the source address to be their own. Creating extension headers when encapsulating is okay since the encapsulator is the source of the outer packet. The problems with EH insertion were enumerated in the discussion on 6man list. Tom > Arashmid > > > > > > -----Original Message----- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: 27 March 2018 11:05 > To: Sri Gundavelli (sgundave) <sgund...@cisco.com> > Cc: dmm@ietf.org > Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 > > On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) > <sgund...@cisco.com> wrote: >> >> >> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote: >> >>>> With regards to SR encapsulation: "this is using IP-in-IP as default. >>>> Why not using UDP encapsulation?" >>> >> >> I am really hoping we will be able to apply SRH insertion without the >> need for IP encapsulation. At least for mobile environments within a >> closed administrative domains, there should be exceptions for >> allowing insertion of SRH by a on-path node. I realize there are >> issues with ICMP error messages hitting the source etc, but we should >> be able to document those issues and specify work arounds. I >> understand there have been discussions on this topic before, but I >> hope authors will find some agreements for the same. >> > Sri, > > There's been quite a bit of discussion on this on 6man list with reference to > draft-voyer-6man-extension-header-insertion. The problem is that extension > header insertion would violate RFC8200: "Extension headers (except for the > Hop-by-Hop Options header) are not processed, inserted, or deleted by any > node along a packet's delivery path". > > In addition to the the protocol ramifications of doing this (dealing with > MTU, ICMP error, etc.) there were questions as to whether the benefit is > significant enough to justify the cost, as well as what does it mean to > define Internet protocols that only work in a "controlled domain". > > I believe 6man is the right place for further discussions on this. > > Tom > > > > >> >> Sri >> <with no chair hat> >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
