RE: [spring] draft-ietf-spring-srv6-network-programming-01

[Ron Bonica <[e-mail]>]

Pablo,

I agree.

               Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[e-mail]>
Sent: Thursday, September 12, 2019 1:45 PM
To: Ron Bonica <[e-mail]>; SPRING WG List <[e-mail]>; [e-mail]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming-01

Ron,

I agree that the text for those two sections is unclear.
Given that this is already covered in depth in draft-xuclad-spring-sr-service-programming, I would propose to remove sections 4.19 and 4.20 from Network-Programming.

Thanks,
Pablo

From: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 12 September 2019 at 15:31
To: "Pablo Camarillo (pcamaril)" <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming-01

Pablo,

Section 4.19 is a bit vague.

In the document, you say that an application can bind to an IPv6 address / SID pair. Does this application have to reside on the SRv6 egress node? Or can the application  reside on and segment egress node? I believe the application can reside on any segment egress node, but I may be wrong.

Does the IP stack duplicate the packet, forwarding one copy and sending the other to the binding application?  Or does the IP stack send the one and only copy of the packet to the binding application? I believe that the IP stack sends the one and only copy of the packet to the binding application, but I may be wrong.

The document says that the binding application can modify the SRH. Can it modify anything else? The payload? Can it respond to the source, as if it were the ultimate destination?


                                                                                  Ron



Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, September 10, 2019 10:15 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; SPRING WG List <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming-01

Ron,

Sections 4.19 introduces how an SRv6 SID may be bound with a service instruction as introduced in https://tools.ietf.org/html/rfc8402#section-1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-1__;Iw!8WoA6RjC81c!XD4lktBxHTm-DwE_6Jf8qvZRC6KijA0TcUhSFBVeNYn8idkxN8PgcWNpg7tlmeYf$>
Section 4.20 provides an informative reference on how to bind a service instruction with non-SR-aware applications.

Cheers,
Pablo.

From: spring <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Date: Friday, 6 September 2019 at 06:44
To: SPRING WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [spring] draft-ietf-spring-srv6-network-programming-01

Authors,

Section 4 of draft-ietf-spring-srv6-network programming has the title "Functions associated with a SID". Sections 4..1 through 4.18 enumerate functions that can be associated with a SID, as one would expect.

Sections 4.19 and 4.20 talk about something unrelated (SR-aware applications and Non-SR-aware applications).

Section 4.19 is vague, but sounds like it might allow transport layer information to be encoded in IPv6 addresses. You might want to clarify this.

                                                                                                  Ron




Juniper Business Use Only