Subject: SRH Open Tickets

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Aug 2018 15:43:31 -0700

Hi,

The following is a summary of the current open issues in the tracker for the SRH draft:

#25	Edge filtering
#26	Edge Filtering and hybrids
#38	Section 3.1 SRH TLV's (Comment 1)
#46	Section 4 SRH Functions (Comment 1)
#54	Section 3.1
#55	Variable Length TLVs
#61	3. Tag field
#62	3.1 Violation of MUST language
#63	SHOULD or MUST only appear one in the packet
#67	Clarifications needed regarding padding objects, HMAC, flag bits
#68	Controlled Domain Issues and Security issues
#69	Adding/Deleting TLVs
#70	"Local Policy" definition
#71	Clarifications needed for Internal and External destination
#72	Normative reference to I-D.filsfils-spring-srv6-network-programming
#64	Various minor issues
#37	Section 3 Segment Routing Header (Comment 4)

Full list can be found at:

https://trac.ietf.org/trac/6man/report/9

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 15 Aug 2018 14:46:40 +0000

Hi Bob,

#37 and #61 appear to be duplicates.

                          Ron

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
> Sent: Tuesday, August 14, 2018 6:44 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: SRH Open Tickets
> 
> Hi,
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 15 Aug 2018 10:21:39 -0700

Hi Bob,

I think justification for creating a new TLV mechanism in routing
headers, as opposed to using destination options that appear before
the routing header, is also an open issue.

I believe there were two reasons cited why TLVs are required in
segment routing header: 1) TLVs need to be added or deleted at
intermediate destinations 2) intermediate destinations may ignore TLVs
and not parse them. The motivation and procedures for adding and
deleting TLVs have not been specified and that is the subject of issue
#69. For the second point, it's not clear on what the motivation is to
allow nodes to ignore TLVs. Presumably, this wold be an allowance for
vendors to not implement TLV processing in the fast path, so that
would be the same motivation where RFC8200 relaxed requirements that
intermediate nodes need to process HBH options. Note that the
provision for HBH options in RFC8200 was needed because the original
requirement was incredibly broad with a scope that included all
anonymous devices in a path; destination options are only processed by
nodes explicit in the path so the scope of the requirement is far
narrower. Nevertheless, if the ability to ignore options is indeed
shown to be a hard requirement, then I would suggest relaxing the
processing requirements for destination options, like done for HBH
options, would be preferable to defining a new TLV mechanism in the
routing header. In any case, this warrants discussion.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Aug 2018 12:15:26 -0700

Tom,

> On Aug 15, 2018, at 10:21 AM, Tom Herbert <[email-masked]> wrote:
> 

I think it would be good if the authors responded to your email.

I am not sure if this is a new issue for the tracker, or not.

Thanks,
Bob

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 21 Aug 2018 16:40:37 +0000

Hi all, I’m getting back from some summer PTO and have a long list of work ahead.  Answers and discussion on this and other TLV related questions are on my queue as well as actions from face to face meetings at IETF 102.

I’ll try not to drop anything over the coming weeks.

Darren

On Aug 15, 2018, at 3:15 PM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:

Tom,

On Aug 15, 2018, at 10:21 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Aug 14, 2018 at 3:43 PM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

#25     Edge filtering

Hi Bob,

Thanks,
Bob

Tom

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Aug 2018 15:33:43 +0000

Hi Darren,

Welcome back!

I can’t remember if we have discussed this before, but in the next version of the SRH draft, could you add a paragraph that details the following:

-         Which SRH fields can be changed between the SR ingress and egress

-         Which SRH fields cannot be changed between the SR ingress and egress

Chairs,

Could we open a ticket to track this.

                                                Ron

From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, August 21, 2018 12:41 PM
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: SRH Open Tickets

Darren

Tom,

Hi,

#25     Edge filtering

Thanks,
Bob

Tom

https://trac.ietf.org/trac/6man/report/9<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_report_9&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=F3lE4XmN36jWX6Cuxx2vaajvc57veAVAYmYyHfBZfr0&s=_EdvyypQSlafEVaGtolsO1IsnmYGRRcdiXS-ID_rEDU&e=>

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=F3lE4XmN36jWX6Cuxx2vaajvc57veAVAYmYyHfBZfr0&s=5ti-wDAT8plRAMyhNFd_hvpOQqAt8AMgiAKirzoygq0&e=>
--------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 22 Aug 2018 21:11:09 +0000

Hi Ron.  We’ve not discussed that in the past but I did cover TLV mutability for AH ICV calculation. RFC2460/8200 and RFC6554 don’t talk about mutability of RH either though I recall text somewhere that the RH type 0 was mutable but predictable.

I’ll add text to the next update on this topic for the remainder of the SRH Fields.

Darren

On Aug 22, 2018, at 11:33 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

Welcome back!

Chairs,

                                                Ron

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, August 21, 2018 12:41 PM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: SRH Open Tickets

Darren

Tom,

Hi,

#25     Edge filtering

Thanks,
Bob

Tom

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Aug 2018 23:29:36 +0000

Hi Darren,

Thanks much!

I was thinking in particular about fields in the first 8 bytes of the SRH (e.g., Hdr Ext Len).

                                                                                              Ron

From: Darren Dukes (ddukes) <[email-masked]>
Sent: Wednesday, August 22, 2018 5:11 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: SRH Open Tickets

Darren

Hi Darren,

Welcome back!

Chairs,

                                                Ron

Darren

Tom,

Hi,

#25     Edge filtering

Thanks,
Bob

Tom

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=KuhgnKLeiXcE7LMkDyDbPTBFAn7hfmTi4s5cQlGg0Os&s=qysDDO8YvORRroqN36JeEA7VTMRdRDceBb9TuchB-kk&e=>
--------------------------------------------------------------------