RE: [spring] How CRH support SFC/Segment Endpoint option?

[Ron Bonica <[e-mail]>]

Folks,

I think that we are all talking past one another. RFC 8200 recommends specific ordering of extension headers for a reason.

IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
	- Hop-by-hop
- Headers processed at every segment endpoint
	- Destination options
	- Routing header
- Headers processed at the ultimate destination only
	- Fragment header
	- Authentication header
	- ESP header
	- Destination Options header

Note that the Destination Options header is the only extension header that can appear twice in a packet. The Destination Options header must immediately precede the Routing header or the upper-0layer header.

 If a packet contains a destination options header, a routing header, a fragment header, and another destination options header:

- the destination options header that precedes the routing header appears in each fragment
- the destination options header that precedes the routing header Is processed on each segment endpoint, before the packet is reassembled
- the destination options header that precedes the upper layer header appears in the first fragment only
- the destination options header that precedes the upper layer header Is processed on the ultimate destination node, after the packet has been reassembled

                                                                      ROn


Juniper Business Use Only

-----Original Message-----
From: Tom Herbert <[e-mail]> 
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter <[e-mail]>
Cc: Robert Raszuk <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail]; 6man <[e-mail]>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]


On Sun, May 24, 2020 at 2:51 PM Brian E Carpenter <[e-mail]> wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk <[e-mail]> wrote:
> >>
> >> Hi Ron,
> >>
> >> I have one small question on the Destination Option Header you keep referencing to carry for example VPN demux instructions.
> >>
> >> As DOH follows Fragment Header it is indeed inspected before CRH.
> >>
> >> So please kindly clarify what is there in the IPv6 packet header which would stop each segment endpoint (during the transit over SR anchors)  which destination is obviously in DA of the arriving packet not to inspect DOH and not trying to execute it ?
> >>
> >> If you could please also provide reference to RFC8200 defining it.
> >>
> > Robert,
> >
> > Look at Destination Options before the routing header in RFC8200.
> > These are intended to be processed at every intermediate destination 
> > in the routing header
>
> That intention is not specified in the text, and IMHO cannot be deduced from the text. Hence my comment on draft-bonica-6man-ext-hdr-update.
>
Brian,

I think it can be deduced. Extension headers need to be processed in order, so destination options before the routing header must be processed before the routing header. If the destination options before the routing were only to be processed at the final destination, then we would need to process the routing header before processing the destination options in order to determine if the destination address is indeed the final destination. More practically, if destination options were only to be processed at the final destination then it doesn't seem like there would be any material between destination options before and those after the routing header (or maybe there was some other intent to have two flavors of destination options?)..

I agree that the text could be clarified, It seems like another case of potential ambiguity in RFC8200 among the terms destination, destination address, final destination, an intermediate destination.
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCueDLaELLoTDx-wnEK6$  was an attempt to calirfy this, at least to clarify the significance of a modifiable destination option (before the routing header).

Tom

>    Brian
>
> > and precede any fragment header.
> >
> > Tom
> >
> >> Keep in mind that in number of networks P routers are also PE routers so executing DOH even if CRH still contains many hops to go may result in very unexpected behaviours. I am sure you recall that L3VPN labels are locally significant and there is no mechanism in place to assure uniqueness of VPN demux values across PEs..
> >>
> >> Why is this important here - because CRH by design is decoupled from any functions or network application handling.
> >>
> >> Many thx,
> >> Robert.
> >>
> >>
> >> On Sun, May 24, 2020 at 3:24 AM Ron Bonica <rbonica=[e-mail]> wrote:
> >>>
> >>> Cheng,
> >>>
> >>>
> >>>
> >>> The CRH is a building block. It has exactly one function. That is, to steer a packet along its delivery path.
> >>>
> >>>
> >>>
> >>> The CRH does not attempt to deliver parameters or metadata to service function instances. It relies on other mechanisms. One possibility is a destination options header that precedes the CRH. I am sure that there are other mechanisms. CRH should be compatible with all of them.
> >>>
> >>>
> >>>
> >>> Personally, I am not an NSH expert. Maybe someone who is can speak up..
> >>>
> >>>
> >>>
> >>>                                                                                               
> >>> Ron
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [e-mail] Administrative 
> >> Requests: 
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i
> >> pv6__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCu
> >> eDLaELLoTD0hgsR60$
> >> -------------------------------------------------------------------
> >> -
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list [e-mail] Administrative 
> > Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!!NEt6yMaO-gk!XLLXuigXPE8uDwP4SF5HfRZ1NBlH1w24-GVBjHk_rvCmqCueD
> > LaELLoTD0hgsR60$
> > --------------------------------------------------------------------
> >