Subject: Ron's Comments WGLC draft-ietf-6man-segment-routing-header-11

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 11 Apr 2018 02:46:33 +0000

Ron, thanks for working with me through the issues you raised, it's been valuable and helped improve the specification.  We still have more work to do but I wanted to update the group on the items we’ve been able to close.  We’ll close off

Reviewed and Closed
#28<https://trac.ietf.org/trac/6man/ticket/28> 2.2 SRv6 Segment (Comment 1)
Rev 12 to describe how interface addresses are handled in end and end.x pseudocode.

#29<https://trac.ietf.org/trac/6man/ticket/29> Section 2.2 SRv6 Segment (Comment 2)

Rev 12 to add this text to 2.1

"A SID is routed through an IPv6 network as any other IPv6 destination address.  IPv6 SIDs, or the prefix(es) covering all SIDs in the "My local SID" table, and their reachability may be distributed by means outside the scope of this document.  For example, [RFC5308] or [RFC5340] may be used to advertise a prefix covering the My Local SID Table."

#31<https://trac.ietf.org/trac/6man/ticket/31> Section 2.2 SRv6 Segment (Comment 4)
Rev 12 to add two descriptions:
1 - Describe default SID handling for addresses within the prefix covering my Local SID Table that have not END or END.X function define.
2 - Describe error handling when receiving packets with SRH and SL!=0 where DA is in interface address that is not in my Local SID Table

#33<https://trac.ietf.org/trac/6man/ticket/33> Section 2.3 Segment Routing (SR) Domain (Comment 1)
Rev 12 to change text to
"The SRH is added to the packet by its source, consistent with the source routing model defined in [RFC8200].  For example:”

#34<https://trac.ietf.org/trac/6man/ticket/34> Section 3 Segment Routing Header (Comment 1)
Rev 12 removes normative references to draft-filsfils-spring-srv6-network-programming, agreement from London was to deal with SRH separately.

#35<https://trac.ietf.org/trac/6man/ticket/35> Section 3 Segment Routing Header (Comment 2)
Rev 12 Removes P Flag for definition in a draft with the usecase - i.e. draft-bashandy-rtgwg-segment-routing-ti-lfa

#36<https://trac.ietf.org/trac/6man/ticket/36> Section 3 Segment Routing Header (Comment 3)
Rev 12 Removes O Flag for definition in a draft with the usecase - i.e. draft-ali-spring-srv6-oam

#39<https://trac.ietf.org/trac/6man/ticket/39> Section 3.1.1 Ingress Node TLV (Comment 1)
Rev 12 Removes the TLV

#40<https://trac.ietf.org/trac/6man/ticket/40> Section 3.1.1 Ingress Node TLV (Comment 2)
Rev 12 Removes the TLV

#41<https://trac.ietf.org/trac/6man/ticket/41> Section 3.1.2 Egress Node TLV (Comment 1)
Rev 12 Removes the TLV

#42<https://trac.ietf.org/trac/6man/ticket/42> Section 3.1.3 Opaque Container TLV Comment 1)
Rev 12 Removes the TLV

#43<https://trac.ietf.org/trac/6man/ticket/43> Section 3.1.6 NSH Carrier TLV (Comment 1)
Rev 12 Removes the NSH TLV for definition in a draft with the usecase - i.e. draft-xuclad-spring-sr-service-chaining

#44<https://trac.ietf.org/trac/6man/ticket/44> Section 3.1.6 NSH Carrier TLV (Comment 2)
Same as #43

#45<https://trac.ietf.org/trac/6man/ticket/45> Section 3.2. SRH and RFC8200 behavior (Comment 1)
Rev 12 removes the text in question, defaulting to definition in RFC8200

#46<https://trac.ietf.org/trac/6man/ticket/46> Section 4 SRH Functions (Comment 1)
Rev 12 removes the reference

#47<https://trac.ietf.org/trac/6man/ticket/47> Section 4.1 Endpoint Function (End) (Comment 1)
Rev 12 removes the multicast comment, any discussion of multicast can be held to a document that concentrates on the usecase.

Responses not reviewed with Ron but likely to close
#52<https://trac.ietf.org/trac/6man/ticket/52> MINOR ISSUES:
U bits are not contiguous given released version of Linux Kernel with H flag support.
A-flag is removed from Rev 12
Ingress/Egress/Opaque TLVs are removed
The SRH draft is the normative document for END and END.X, draft-filsfils-spring-srv6-network-programming will be changed to reference it.

Issues from Ron that are in progress:
#27,28,32 - all share the same fate, rough agreement on what’s needed, I’m working on text.
#37 - adding text
#38 - re-review with Ron
#48 - adding text
#51 - review with Ron

Thanks
  Darren

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Apr 2018 20:59:25 +0000

Hi Darren,

Thanks for the collaboration. It has been both productive and fun!

WG participants,

To update, the WG, Darren and I have worked out a good many issues together. A new version of the draft is forthcoming and we will probably be able to close out many issues in the tracker after that draft revision has been published. However, we probably should not close any issues until the new draft version is available.

A few significant issues remain to be resolved. The genesis of these problems is that a SID is not always an IPv6 address. It can be a locator:instruction:parameter structure. When we swap such a SID into the IPv6 Destination Address field, we change something fundamental about IPv6 packet processing. In the past, when a packet arrived at its destination, processing of the basic header was complete. We were ready to move on to the next header. Now, when a packet arrives at the node represented by a locator, the instruction encoded in the destination address remains to be executed. So, it is unclear as to whether SID/SRH processing is complete.

This problem manifests itself as multiple questions regarding the status of an SRH when SL==0.

Darren and I are working on text that articulates and resolves the problem. Please stand by for updates.

                                                                                Ron

From: Darren Dukes (ddukes) <[email-masked]>
Sent: Tuesday, April 10, 2018 10:47 PM
To: Ron Bonica <[email-masked]>; IPv6 List <[email-masked]>
Subject: Ron's Comments WGLC draft-ietf-6man-segment-routing-header-11

Reviewed and Closed
#28<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_28&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=e1cKYQYWpeCTM09oKlQb81ZEChBixJ6A8eu-k-YFlaM&e=> 2.2 SRv6 Segment (Comment 1)
Rev 12 to describe how interface addresses are handled in end and end.x pseudocode.

#29<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_29&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=xc9dZqqCCbNEhVSQ-ebmUQWvZADZCs5zmBaOnZVyrtQ&e=> Section 2.2 SRv6 Segment (Comment 2)

#31<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_31&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=pan8ZDb7cOlPUIu-lKAZXS68KCwT6oaYSI6NN57uiZk&e=> Section 2.2 SRv6 Segment (Comment 4)
Rev 12 to add two descriptions:
1 - Describe default SID handling for addresses within the prefix covering my Local SID Table that have not END or END.X function define.
2 - Describe error handling when receiving packets with SRH and SL!=0 where DA is in interface address that is not in my Local SID Table

#33<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_33&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=pt2-q447oceRqk7rpXeGOUiy8JsCbO9V916fW8v3nOA&e=> Section 2.3 Segment Routing (SR) Domain (Comment 1)
Rev 12 to change text to
"The SRH is added to the packet by its source, consistent with the source routing model defined in [RFC8200].  For example:”

#34<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_34&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=pooVOo6NJcyFE5J4cp62kk7WLr00OqRAbZflmKl8jsQ&e=> Section 3 Segment Routing Header (Comment 1)
Rev 12 removes normative references to draft-filsfils-spring-srv6-network-programming, agreement from London was to deal with SRH separately.

#35<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_35&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=Ytt6PJ12JTzVlnLcD1Slbs2DoM1-qO3GJAytrqheT9s&e=> Section 3 Segment Routing Header (Comment 2)
Rev 12 Removes P Flag for definition in a draft with the usecase - i.e. draft-bashandy-rtgwg-segment-routing-ti-lfa

#36<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_36&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=qi7ic_98fUnI97-l27_1pcUAu_i1G6n0IuWLxV4XPI4&e=> Section 3 Segment Routing Header (Comment 3)
Rev 12 Removes O Flag for definition in a draft with the usecase - i.e. draft-ali-spring-srv6-oam

#39<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_39&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=4iVQMJmx8pFb2umoTCP8Q5YpHUc3zlrus89ShZsOTs0&e=> Section 3.1.1 Ingress Node TLV (Comment 1)
Rev 12 Removes the TLV

#40<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_40&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=TZcvKRbTzyjvSyFg-YNF2oRrfwZA2gY16AitDelq6zE&e=> Section 3.1.1 Ingress Node TLV (Comment 2)
Rev 12 Removes the TLV

#41<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_41&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=oTOsltlhmOq0toYRqHvdjPH3fQ2H1FQD3K2Eqx1xozw&e=> Section 3.1.2 Egress Node TLV (Comment 1)
Rev 12 Removes the TLV

#42<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_42&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=rG5SywX1Mr7G3sO-EnwBcXz8NVwDkdkZGeqzYWD3q0M&e=> Section 3.1.3 Opaque Container TLV Comment 1)
Rev 12 Removes the TLV

#43<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_43&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=c3Ix7g1lBPvebZHIEZB5S9NebhTCzc39FCnGcC-C83c&e=> Section 3.1.6 NSH Carrier TLV (Comment 1)
Rev 12 Removes the NSH TLV for definition in a draft with the usecase - i.e. draft-xuclad-spring-sr-service-chaining

#44<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_44&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=Q9wXBTcIx2asOoeeYz8_mfmkWqoYJdys8Rmj21k4QT4&e=> Section 3.1.6 NSH Carrier TLV (Comment 2)
Same as #43

#45<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_45&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=EJ_F0OJkWDmtd11D2O_Idpveo7uKBLymFi-CdCdLNUA&e=> Section 3.2. SRH and RFC8200 behavior (Comment 1)
Rev 12 removes the text in question, defaulting to definition in RFC8200

#46<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_46&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=WmEk-JcBFSXNpttkhEny3pXDvno_mOJy-Vd7GNaOyzU&e=> Section 4 SRH Functions (Comment 1)
Rev 12 removes the reference

#47<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_47&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=dtB3h6rb82lB_IIllAg5G5wSuDfNfCq1JxPI2Eebi6I&e=> Section 4.1 Endpoint Function (End) (Comment 1)
Rev 12 removes the multicast comment, any discussion of multicast can be held to a document that concentrates on the usecase.

#52<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_52&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=oOUBMEEIyKq4ERNkpwQAkwrbiTrCq6Cy4Abojb_wohI&s=tSuiUiTQT0ilL_jA7UXlMbWBQseKZb1AoGD55NXkJto&e=> MINOR ISSUES:

Thanks
  Darren

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 Apr 2018 14:10:24 -0700

Ron,

> On Apr 11, 2018, at 1:59 PM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Darren,
> 

Right.  The change can be captured in the comments in the tracker, but the issue shouldn’t be closed until a new draft with the text is published.

Thanks,
Bob

> #28 2.2 SRv6 Segment (Comment 1)
> #29 Section 2.2 SRv6 Segment (Comment 2)
> #31 Section 2.2 SRv6 Segment (Comment 4)
> #33 Section 2.3 Segment Routing (SR) Domain (Comment 1)
> Rev 12 to change text to
> #34 Section 3 Segment Routing Header (Comment 1)
> #35 Section 3 Segment Routing Header (Comment 2)
> #36 Section 3 Segment Routing Header (Comment 3)
> #39 Section 3.1.1 Ingress Node TLV (Comment 1)
> Rev 12 Removes the TLV
> 
> #40 Section 3.1.1 Ingress Node TLV (Comment 2)
> Rev 12 Removes the TLV
> 
> #41 Section 3.1.2 Egress Node TLV (Comment 1)
> Rev 12 Removes the TLV
> 
> #42 Section 3.1.3 Opaque Container TLV Comment 1)
> Rev 12 Removes the TLV
> 
> #43 Section 3.1.6 NSH Carrier TLV (Comment 1)
> #44 Section 3.1.6 NSH Carrier TLV (Comment 2)
> Same as #43
> 
> #45 Section 3.2. SRH and RFC8200 behavior (Comment 1)
> #46 Section 4 SRH Functions (Comment 1)
> #47 Section 4.1 Endpoint Function (End) (Comment 1)
> #52 MINOR ISSUES:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

Acking both Ron’s ongoing collaboration and the expectation that we don’t close items until the new draft is published.

Darren

On 2018-04-11, 5:10 PM, "Bob Hinden" <[email-masked]> wrote:

    Ron,

    
    Thanks,
    Bob

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Apr 2018 13:05:18 +0000

Thanks!

> -----Original Message-----
> Sent: Wednesday, April 11, 2018 5:21 PM
> To: Bob Hinden <[email-masked]>; Ron Bonica
> <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> Subject: Re: Ron's Comments WGLC draft-ietf-6man-segment-routing-
> header-11
> 
> Acking both Ron’s ongoing collaboration and the expectation that we don’t
> close items until the new draft is published.
> 
> 
> 
> Darren
> 
> 
> 
>     > To update, the WG, Darren and I have worked out a good many issues
> together. A new version of the draft is forthcoming and we will probably be
> able to close out many issues in the tracker after that draft revision has been
> published. However, we probably should not close any issues until the new
> draft version is available.
> 
> 
> 
>     Right.  The change can be captured in the comments in the tracker, but the
> issue shouldn’t be closed until a new draft with the text is published.
> 
> 
> 
>     Thanks,
> 
>     Bob
> 
> 
> 
> 
> 
>     >
> 
>     > A few significant issues remain to be resolved. The genesis of these
> problems is that a SID is not always an IPv6 address. It can be a
> locator:instruction:parameter structure. When we swap such a SID into the
> IPv6 Destination Address field, we change something fundamental about
> IPv6 packet processing. In the past, when a packet arrived at its destination,
> processing of the basic header was complete. We were ready to move on to
> the next header. Now, when a packet arrives at the node represented by a
> locator, the instruction encoded in the destination address remains to be
> executed. So, it is unclear as to whether SID/SRH processing is complete.
> 
>     >
> 
>     > Ron, thanks for working with me through the issues you raised, it's been
> valuable and helped improve the specification.  We still have more work to
> do but I wanted to update the group on the items we’ve been able to close.
> We’ll close off
> 
>     >
> 
>     > Reviewed and Closed
> 
>     > "A SID is routed through an IPv6 network as any other IPv6 destination
> address.  IPv6 SIDs, or the prefix(es) covering all SIDs in the "My local SID"
> table, and their reachability may be distributed by means outside the scope
> of this document.  For example, [RFC5308] or [RFC5340] may be used to
> advertise a prefix covering the My Local SID Table."
> 
>     >
> 
>     >
> 
>     > 1 - Describe default SID handling for addresses within the prefix covering
> my Local SID Table that have not END or END.X function define.
> 
>     > 2 - Describe error handling when receiving packets with SRH and SL!=0
> where DA is in interface address that is not in my Local SID Table
> 
>     >
> 
>     > "The SRH is added to the packet by its source, consistent with the source
> routing model defined in [RFC8200].  For example:”
> 
>     >
> 
>     >
> 
>     > Rev 12 removes normative references to draft-filsfils-spring-srv6-
> network-programming, agreement from London was to deal with SRH
> separately.
> 
>     >
> 
>     > Rev 12 Removes P Flag for definition in a draft with the usecase - i.e.
> draft-bashandy-rtgwg-segment-routing-ti-lfa
> 
>     >
> 
>     > Rev 12 Removes the NSH TLV for definition in a draft with the usecase -
> i.e. draft-xuclad-spring-sr-service-chaining
> 
>     >
> 
>     > Rev 12 removes the multicast comment, any discussion of multicast can
> be held to a document that concentrates on the usecase.
> 
>     >
> 
>     >
> 
>     > The SRH draft is the normative document for END and END.X, draft-
> filsfils-spring-srv6-network-programming will be changed to reference it.
> 
>     >
> 
>     >
> 
>     >
> 
>     > Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=kVxw6Qc6M5wH_Sp9XI4GLNbB6p7-MJ-
> zJRk3epgmWws&s=6zujryAP7qdWbD79naGth7zX2_tUoVhtW4z8_xl9qsA&e=
>