Subject: Re: draft-ietf-6man-segment-routing-header issue #63 - nit remains

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 1 May 2018 14:23:40 +0000

Hi Adrian. In RFC8200 Routing header processing is only defined for packets destined to a local address (received packets), I wanted to call attention to that in this section but should have been more specific.  How does the following text sit with you?

OLD:
   Extension header processing is as defined in RFC8200 for packets
   destined to a local IPv6 address.
NEW:
   Routing header processing is as defined in RFC8200 for packets
   destined to a local IPv6 address.

Darren

On Apr 23, 2018, at 6:16 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Your new 3.2 removes my concern by removing the restatement of text from 8200 and leaving us to read 8200 for normative behavior: good.

But you have a nit in your new text...

   Extension header processing is as defined in RFC8200 for packets
   destined to a local IPv6 address.

This appears to say that processing not destined to a local address are handled differently from RFC8200. But presumably all processing is per 8200. So how about...

   Extension header processing is as defined in RFC8200. If the SRH
   is present on a packet destined to a local IPv6 address, it is
   processed as follows (DA represents the destination address in
   the IPv6 header):

Adrian

From: Darren Dukes (ddukes) [mailto:[email-masked]]
Sent: 23 April 2018 21:48
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: WG last call review of draft-ietf-6man-segment-routing-header

Hi Adrian.  Thanks for your review of rev11.

The following issue numbers were open by you and are closed in revision revision 12. Please respond to this email acknowledging the closures so Bob can record it.
#57<https://trac.ietf.org/trac/6man/ticket/57>, #58<https://trac.ietf.org/trac/6man/ticket/58>, #59<https://trac.ietf.org/trac/6man/ticket/59>, #60<https://trac.ietf.org/trac/6man/ticket/60>, #61<https://trac.ietf.org/trac/6man/ticket/61>, #63<https://trac.ietf.org/trac/6man/ticket/63>,

#62<https://trac.ietf.org/trac/6man/ticket/62> is not closed yet, sending me specific examples would be useful.

#64<https://trac.ietf.org/trac/6man/ticket/64> Still open.  It contains your minor issues/Nits.  19 of which are fixed/resolvable in rev12, 6 remain open.  I’ll send a separate email on this.

Thanks!
 Darren

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 May 2018 17:05:14 +0100

Hey Darren,
 
I don't want to make a big thing out of what really is a nit. Your proposed change makes sense.
 
The point I was trying to make is that this text says how the routing header is processed when the packet is destined to a local address and leaves open how the header is processed when the packet is not destined to a local address. I think 8200 also covers that: specifically, the routing header must not be processed at an interim node.
 
I was just proposing to be tight about this by delegating all processing to 8200. Not sure why that is a worry to you.
 
Cheers,
Adrian
 
From: Darren Dukes (ddukes) [mailto:[email-masked]] 
Sent: 01 May 2018 15:24
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: draft-ietf-6man-segment-routing-header issue #63 - nit remains

OLD:

Darren

On Apr 23, 2018, at 6:16 PM, Adrian Farrel <[email-masked]> wrote:

 

 
Adrian

From: Darren Dukes (ddukes) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: 23 April 2018 21:48
To:  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: WG last call review of draft-ietf-6man-segment-routing-header

The following issue numbers were open by you and are closed in revision revision 12. Please respond to this email acknowledging the closures so Bob can record it.
 <https://trac.ietf.org/trac/6man/ticket/57> #57,  <https://trac.ietf.org/trac/6man/ticket/58> #58,  <https://trac.ietf.org/trac/6man/ticket/59> #59,  <https://trac.ietf.org/trac/6man/ticket/60> #60,  <https://trac.ietf.org/trac/6man/ticket/61> #61,  <https://trac.ietf.org/trac/6man/ticket/63> #63, 
 
 <https://trac.ietf.org/trac/6man/ticket/62> #62 is not closed yet, sending me specific examples would be useful.
 
 <https://trac.ietf.org/trac/6man/ticket/64> #64 Still open.  It contains your minor issues/Nits.  19 of which are fixed/resolvable in rev12, 6 remain open.  I’ll send a separate email on this.
 
Thanks!
 Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 1 May 2018 16:25:17 +0000

I fully agree with the point you were trying to make, and I have no worry about delegating processing to 8200.

I suggested this text since I wanted to keep the section specific to Routing Header processing (specifically Segment Routing Header), not generic to any extension header.

Darren

On May 1, 2018, at 12:05 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hey Darren,

Cheers,
Adrian

OLD:

Darren

Adrian

Thanks!
 Darren

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 May 2018 17:54:03 +0100

Yes. so how about we combine our wordsmithing to read
 
   Routing header processing is as defined in RFC8200. If the SRH
   is present on a packet destined to a local IPv6 address, it is
   processed as follows (DA represents the destination address in
   the IPv6 header):
 
A
 
Sent: 01 May 2018 17:25

 
Darren

On May 1, 2018, at 12:05 PM, Adrian Farrel <[email-masked]> wrote:
 
Hey Darren,

 
 
Cheers,
Adrian

 
OLD:

Darren

On Apr 23, 2018, at 6:16 PM, Adrian Farrel < <mailto:[email-masked]> [email-masked]> wrote:

 

 
Adrian

 

 
Thanks!
 Darren