Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Sasha,

I think that we are in agreement regarding points 1 and 2. Issue #3 is the bone 
of contention.

More inline...

   Ron



Juniper Business Use Only


From: spring  on behalf of Alexander Vainshtein 

Sent: Wednesday, March 27, 2024 11:48 AM
To: Ron Bonica 
Cc: Tom Herbert ; spring@ietf.org ; 
Alvaro Retana ; Robert Raszuk ; 
Stewart Bryant ; Andrew Alston - IETF 

Subject: Re: [spring] [EXTERNAL] Re: Chair Review of 
draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


Ron,

I think we are – in a way.



  1.  We agree that SRv6 SIDs are not aligned with the IPv6 addressing 
architecture as defined in RFC 4291
 *   This is recognized by the 6MAN WG and there seems to be a consensus 
there about the way this can be handled
 *   IMHO and FWIW their proposal is good enough - but beauty is always in 
the eye of the beholder
  2.  We agree (or so I think) that certain things that happen around SRv6 
would be violations of RFC 8200
 *   I have not heard that 6MAN WG has ever agreed to these violations
 *   From my POV such violations must be blocked if SRv6 remains part of 
IPv6
 *   I think that the SPRING WG recognizes the limits set by RFC 8200, will 
refrain from crossing these limits
  3.  I object to separation of SRv6 from IPv6 using a new optional Ethertype 
because:
 *
It is by far too late for that, and, probably, has been too late before SRv6 
has been born

[RB] Is it? I think that we have a choice between correcting the error now or 
watching engineering debt accumulate over the years. Both options are painful. 
In my experience, it is better to endure a sharp pain that ends quickly than a 
dull pain that lasts forever.


 *   You cannot force people to use an optional Ethertype while the normal 
IPv6 Ethertype is allowed, and therefore nothing would be really achieved this 
way



[RB] I agree that an optional Ethertype will achieve little. It should be 
mandatory.





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Sasha,

Are we in violent agreement ?

 Ron


Juniper Business Use Only


From: Alexander Vainshtein 
Sent: Wednesday, March 27, 2024 10:44 AM
To: Stewart Bryant ; Andrew Alston - IETF 

Cc: Tom Herbert ; Ron Bonica ; 
spring@ietf.org ; Alvaro Retana ; 
Robert Raszuk 
Subject: RE: [EXTERNAL] Re: [spring] Chair Review of 
draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


Stewart, Andrew, and all,

More of the same,



I suspect that the people who call for a new Ethernet for SRv6 are trying to 
lock the stable door after the horse has been stolen.



If you look at RFC 
8159<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8159__;!!NEt6yMaO-gk!AHyM-ap0A7dnGHB0l7_SU_vvPDFrs7nUD9QTRe-ckiL4RyBPiZcPvosjG1BGowDA8dYkhdeOTAonVOUfI_hiwcMJaA$>
 (Standards Track, published 7 years ago long before SRv6) you will see that it 
uses IPv6 addresses in a way that, IMHO,  violates RFC 4291.

Quoting from Section 2 of this document (the relevant text is highlighted):



   The L2TPv3 control plane defined in 
[RFC3931<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc3931__;!!NEt6yMaO-gk!AHyM-ap0A7dnGHB0l7_SU_vvPDFrs7nUD9QTRe-ckiL4RyBPiZcPvosjG1BGowDA8dYkhdeOTAonVOUfI_gW88NcnA$>]
 is not used for this

   encapsulation.  The management plane is used to create and maintain

   matching configurations at either end of each tunnel.  Local

   configuration by the management plane creates a one-to-one mapping

   between the access-side L2 attachment circuit and the IP address used

   in the network-side IPv6 encapsulation.



I have been the RTGWG reviewer of the draft that developed into this RFC, and I 
have then pointed to potential violations of the IPv6 addressing architecture 
in my review – but this did not prevent progressing of this draft.



My 2c,

Sasha



From: Alexander Vainshtein
Sent: Wednesday, March 27, 2024 3:41 PM
To: Stewart Bryant 
Cc: Tom Herbert ; Ron Bonica ; 
spring@ietf.org; Alvaro Retana ; Robert Raszuk 
; Andrew Alston - IETF 

Subject: RE: [EXTERNAL] Re: [spring] Chair Review of 
draft-ietf-spring-srv6-srh-compression-11



Stewart,

The 6man-sid 
draft<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-06*section-5__;Iw!!NEt6yMaO-gk!AHyM-ap0A7dnGHB0l7_SU_vvPDFrs7nUD9QTRe-ckiL4RyBPiZcPvosjG1BGowDA8dYkhdeOTAonVOUfI_iVDqVg8A$>
 is a WG document of the 6MAN that has passed the WG Last Call in this WG and 
has been submitted by the WG to IESG for approval.







The shepherd write-up for this 
draft<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-sids/shepherdwriteup/__;!!NEt6yMaO-gk!AHyM-ap0A7dnGHB0l7_SU_vvPDFrs7nUD9QTRe-ckiL4RyBPiZcPvosjG1BGowDA8dYkhdeOTAonVOUfI_haYFlOhA$>
 says that “No agreement of the WG that owns that protocol or particularly 
rough consensus were observed” and that “Nobody has  threatened an appeal or 
otherwise indicated extreme discontent”.



IMHO and FWIW this counts as “the agreement of the WG that owns that protocol” 
in your email. What did I miss?



Regards,

Sasha



From: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Sent: Wednesday, March 27, 2024 3:27 PM
To: Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Tom 
Herbert mailto:t...@herbertland.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
spring@ietf.org<mailto:spring@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Subject: [EXTERNAL] Re: [spring] Chair Review of 
draft-ietf-spring-srv6-srh-compression-11



Any router that has interfaces of mixed type has to be able to re-write the 
datalink header. Changing the Ethertype is a trivial part of changing the Mac 
header and should therefore be considered a fundamental part of the IETF IP 
forwarding plane.



In reading this discussion I am reminded of very public statements made to 
other SDOs that if you want to diverge an IETF protocol from its standard 
definition you MUST either get the agreement of the WG that owns that protocol 
(in this case 6man) or get a new Ethertype and a new name for the protocol.



I think that those proposing that SRv6 and all its subvariants should get a new 
Ethertype are correct both from an IETF policy PoV and a pragmatic engineering 
PoV.



If we do not eat our own dog food here we will not be able to hold the line 
when other organisations propose incompatible changes to our protocols. As you 
can imagine if uncontrolled divergent changes happen that is unlikely to end 
well for the Internet.



Regards



Stewart



On 27 Mar 2024, at 1:05 pm, Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>
 wrote:



That still does not negate the point – if hardware is capable of stripping 

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Folks,

Previously in this thread, Antoine Fressancourt wrote:

" I think everyone here has realized that the current discussion about C-SID is 
a proxy for some people’s discontent with Segment Routing at large".

At first, I took offense to this comment and was not going to grace it with a 
response. It is bad form to infer the motivation of others. But now, I 
understand why Antoine might make such a comment.

SRv6 has had a strained relationship with IPv6 since the beginning. Do you 
remember:


  *
The debates about inserting and removing extension headers in flight
  *
The debates SRv6 and the IPv6 Addressing architecture

The checksum discussion is yet another manifestation of the tension between the 
SRv6 forwarding plane and the IPv6 forwarding plane. Pointing out that tension 
is not an attack on SRv6. It is a contribution to SRv6.

SRv6 can benefit by diverging and forking from IPv6. This is likely because the 
SRv6 use-case is different from the IPv6 use-case. These differences will only 
become more pronounced in the future. And as use-cases diverge, so will 
requirements. And as requirements diverge, the tension between the two 
forwarding planes will also increase.

This doesn't mean that SRv6 is a bad thing. It only means that its future is 
different from that of IPv6.

Ron






Juniper Business Use Only


From: Andrew Alston - IETF 
Sent: Wednesday, March 27, 2024 9:01 AM
To: Ron Bonica ; Antoine FRESSANCOURT 
; Tom Herbert 
Cc: Alexander Vainshtein ; spring@ietf.org 
; Robert Raszuk ; Alvaro Retana 

Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


100% agree with t hat – the checksum issue is another incremental issue – the 
sids document documents multiple other issues – and I’m far from convinced it’s 
a complete list of issues.  I do agree with that Tom that a draft that 
documents all the divergence that already exists would be useful – and I’m 
happy to co-author on that.



Thanks



Andrew






Internal All Employees

From: Ron Bonica 
Date: Wednesday, 27 March 2024 at 15:59
To: Antoine FRESSANCOURT , Andrew Alston - 
IETF , Tom Herbert 
Cc: Alexander Vainshtein , spring@ietf.org 
, Robert Raszuk , Alvaro Retana 

Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Antoine,



The checksum issue is not the first to make us consider whether SRv6 should be 
forked from IPv6. Nor is it the most significant.



Please take a look at draft-ietf-6man-sids. That exercise in equivocation would 
not have been necessary if SRv6 more clearly conformed to IPv6 standards.



Ron



Juniper Business Use Only


Juniper Business Use Only



From: Antoine FRESSANCOURT 
Sent: Wednesday, March 27, 2024 4:42 AM
To: Andrew Alston - IETF ; Tom 
Herbert ; Ron Bonica 
Cc: Alexander Vainshtein ; spring@ietf.org 
; Robert Raszuk ; Alvaro Retana 

Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11



[External Email. Be cautious of content]



Hello,



I think it is a bit odd that the question that led us to discuss whether SRv6 
was an extension of IPv6 or a separate dataplane protocol on the ground of 
SRv6’s divergence from the IPv6 standard came from a question about whether 
middleboxes, which addresses are not in the packet’s IPv6 header, should be 
able to check the correctness of a L4 checksum, in a layer that they should not 
mess with because they are not an end of the packet forwarding procedure.



If we want to talk about layer violations or non-conformance to standards, I 
suggest we come back to the initial issue and determine clearly whether those 
middleboxes’ behavior makes sense or not (and you guessed I think they should 
not mess with L4 checksum). Maybe this is a question to V6ops, maybe we should 
clarify what is a packet’s recipient per the RFC Andrew Alston has cited, but I 
think it is an issue that is more general than C-SID’s discussion.



Best regards,

Antoine Fressancourt



From: spring  On Behalf Of Andrew Alston - IETF
Sent: mercredi 27 mars 2024 07:25
To: Tom Herbert ; Ron Bonica 
Cc: Alexander Vainshtein ; spring@ietf.org; 
Robert Raszuk ; Alvaro Retana 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11



Tom,



I believe a number of the differences are highlighted in draft-ietf-6man-sids.



Though that does not go as far as to say they ipv6 and srv6 are not the same 
thing – it does highlight that there are key deviations between srv6 and 
rfc4291 for example.



(I hit discuss on this when I was still an AD as seen here 
https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/#draft-ietf-6man-sids_andrew-alston<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/*dr

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Antoine,

The checksum issue is not the first to make us consider whether SRv6 should be 
forked from IPv6. Nor is it the most significant.

Please take a look at draft-ietf-6man-sids. That exercise in equivocation would 
not have been necessary if SRv6 more clearly conformed to IPv6 standards.

Ron


Juniper Business Use Only


From: Antoine FRESSANCOURT 
Sent: Wednesday, March 27, 2024 4:42 AM
To: Andrew Alston - IETF ; Tom 
Herbert ; Ron Bonica 
Cc: Alexander Vainshtein ; spring@ietf.org 
; Robert Raszuk ; Alvaro Retana 

Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


Hello,



I think it is a bit odd that the question that led us to discuss whether SRv6 
was an extension of IPv6 or a separate dataplane protocol on the ground of 
SRv6’s divergence from the IPv6 standard came from a question about whether 
middleboxes, which addresses are not in the packet’s IPv6 header, should be 
able to check the correctness of a L4 checksum, in a layer that they should not 
mess with because they are not an end of the packet forwarding procedure.



If we want to talk about layer violations or non-conformance to standards, I 
suggest we come back to the initial issue and determine clearly whether those 
middleboxes’ behavior makes sense or not (and you guessed I think they should 
not mess with L4 checksum). Maybe this is a question to V6ops, maybe we should 
clarify what is a packet’s recipient per the RFC Andrew Alston has cited, but I 
think it is an issue that is more general than C-SID’s discussion.



Best regards,

Antoine Fressancourt



From: spring  On Behalf Of Andrew Alston - IETF
Sent: mercredi 27 mars 2024 07:25
To: Tom Herbert ; Ron Bonica 
Cc: Alexander Vainshtein ; spring@ietf.org; 
Robert Raszuk ; Alvaro Retana 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11



Tom,



I believe a number of the differences are highlighted in draft-ietf-6man-sids.



Though that does not go as far as to say they ipv6 and srv6 are not the same 
thing – it does highlight that there are key deviations between srv6 and 
rfc4291 for example.



(I hit discuss on this when I was still an AD as seen here 
https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/#draft-ietf-6man-sids_andrew-alston<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/*draft-ietf-6man-sids_andrew-alston__;Iw!!NEt6yMaO-gk!DU6XFSbAExHKgAEdnXtcbm0bN6GhqSO9_14l7vRnh75fEvCDgOl6QJyZIsqfBfDqWRTFZ654z1iUaN--S3jdcz5hW_LM$>
  because as I said in the discuss I believe that the sids document was 
attempting to have it both ways – and I don’t believe you can do that)



I also point out that if we do agree to diverge between srv6 and ipv6 – this 
can be done without creating further complexity – and by allowing for an 
*optional* ethertype as per 
https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/__;!!NEt6yMaO-gk!DU6XFSbAExHKgAEdnXtcbm0bN6GhqSO9_14l7vRnh75fEvCDgOl6QJyZIsqfBfDqWRTFZ654z1iUaN--S3jdc2SoAa0p$>
 this also would allow operators the choice to run srv6 in a way that makes 
them comfortable or not – without complexity and actually *enhance* the 
deployment of srv6 – because there are operators out there that will never run 
srv6 while we continue to insist its ipv6 but violate the ipv6 standards – at 
the expense of security and other aspects.



I have never understood the vendor resistence to giving operators this choice 
though – especially when it would actually help get their stuff deployed in 
more networks potentially.



Andrew





Internal All Employees

From: Tom Herbert mailto:t...@herbertland.com>>
Date: Wednesday, 27 March 2024 at 02:52
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, 
spring@ietf.org<mailto:spring@ietf.org> 
mailto:spring@ietf.org>>, Andrew Alston - IETF 
mailto:andrew-i...@liquid.tech>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
>
> Sasha,
>
> At the moment when SRv6 diverges from  IPv6, the two evolutionary branches 
> are identical. If SRv6 needs link locals, it can use them.
>
> However, SRv6 now has the freedom to evolve in ways that IPv6 cannot.

Hi Ron,

That assumes that SRv6 is forked from IPv6? It might be nice for
someone to write up an I-D to really clarify the relationship between
SRv6 and IPv6.

Tom

>
>   Ron
&g

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Tom,

I am assuming that we have volunteered each other to write the draft. Does that 
mean that we will co-author?

  Ron



Juniper Business Use Only


From: Tom Herbert 
Sent: Tuesday, March 26, 2024 7:52 PM
To: Ron Bonica 
Cc: Alexander Vainshtein ; spring@ietf.org 
; Andrew Alston - IETF ; Robert 
Raszuk ; Alvaro Retana 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica  wrote:
>
> Sasha,
>
> At the moment when SRv6 diverges from  IPv6, the two evolutionary branches 
> are identical. If SRv6 needs link locals, it can use them.
>
> However, SRv6 now has the freedom to evolve in ways that IPv6 cannot.

Hi Ron,

That assumes that SRv6 is forked from IPv6? It might be nice for
someone to write up an I-D to really clarify the relationship between
SRv6 and IPv6.

Tom

>
>   Ron
>
> Juniper Business Use Only
>
> 
> From: Alexander Vainshtein 
> Sent: Tuesday, March 26, 2024 4:24 PM
> To: Ron Bonica 
> Cc: spring@ietf.org ; Andrew Alston - IETF 
> ; Robert Raszuk ; Tom Herbert 
> ; Alvaro Retana 
> Subject: Re: [spring] Chair Review of 
> draft-ietf-spring-srv6-srh-compression-11
>
>
> [External Email. Be cautious of content]
>
> Ron,
> I am not sure you can separate just the forwarding plane of SRv6 and IPv6.
>
> E.g., what would happen to all the IPv6 mechanisms that use link-local IPv6 
> addresses?
>
> Replicating these mechanisms does not make much sense to me.
>
> My 2c,
> Sasha
>
>
> Get Outlook for Android
>
>
> Juniper Business Use Only
>
> 
> From: Ron Bonica 
> Sent: Tuesday, March 26, 2024 8:36:49 PM
> To: Alexander Vainshtein 
> Cc: spring@ietf.org ; Andrew Alston - IETF 
> ; Robert Raszuk ; Tom Herbert 
> ; Alvaro Retana 
> Subject: [EXTERNAL] Re: [spring] Chair Review of 
> draft-ietf-spring-srv6-srh-compression-11
>
> Sasha,
>
> Good point. In my previous email, I didn't mean suggest that we should 
> divorce SRv6 from the entire suite of Internet protocols. I only meant that 
> we should divorce the SRv6 forwarding plane from the IPv6 forwarding plane. 
> BGP could continue to distribute SIDS exactly as is distributes MPLS service 
> labels today.
>
> You bring up another good point about the parallel evolution of SRv6 and 
> IPv6. Yes, this is an engineering trade off. If you divorce SRv6 from IPv6, 
> and IPv6 develops a useful new feature, SRv6 might need to develop that 
> feature, too. However, if you bind SRv6 to IPv6, SRv6 must strictly adhere to 
> IPv6 standards, both now and in the future.
>
> Which is more painful?
>
>        Ron
>
> Juniper Business Use Only
>
> 
> From: Alexander Vainshtein 
> Sent: Tuesday, March 26, 2024 1:56 PM
> To: Ron Bonica 
> Cc: spring@ietf.org ; Andrew Alston - IETF 
> ; Robert Raszuk ; Tom Herbert 
> ; Alvaro Retana 
> Subject: RE: [spring] Chair Review of 
> draft-ietf-spring-srv6-srh-compression-11
>
>
> [External Email. Be cautious of content]
>
> Ron and all,
>
> I respectfully disagree with the proposal of separation of SRv6 from the 
> existing IPv6.
>
>
>
> IMHO and FWIW the most important added value of SRv6 is its ability to 
> provide BGP-based overlay services without any changes in the P routers as 
> described in Introduction of RFC 9252:
>
>
>
> To provide SRv6 service with best-effort connectivity, the egress PE signals 
> an SRv6 Service SID with the BGP overlay service route. The ingress PE 
> encapsulates the payload in an outer IPv6 header where the destination 
> address is the SRv6 Service SID provided by the egress PE. The underlay 
> between the PEs only needs to support plain IPv6 forwarding [RFC8200].
>
>
>
> To me this means that SRv6 services can benefit from incremental deployment 
> when new forwarding capabilities (implementation of SRv6 Endpoint Behaviors) 
> would be initially available just in the relevant PEs.
>
>
>
> And best-effort BGP-based SRv6 services would scale up much better than 
> best-effort BGP-based services on top of a SR-MPLS underlay because:
>
> With SR-MPLS, the forwarding HW of the ingress PE would have to maintain at 
> least one dedicated egress encapsulation information element for the local 
> representation of each service instance in each egress PE of this service 
> (the label stack that delivers the packet to 

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Sasha,

At the moment when SRv6 diverges from  IPv6, the two evolutionary branches are 
identical. If SRv6 needs link locals, it can use them.

However, SRv6 now has the freedom to evolve in ways that IPv6 cannot.

  Ron


Juniper Business Use Only


From: Alexander Vainshtein 
Sent: Tuesday, March 26, 2024 4:24 PM
To: Ron Bonica 
Cc: spring@ietf.org ; Andrew Alston - IETF 
; Robert Raszuk ; Tom Herbert 
; Alvaro Retana 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


Ron,
I am not sure you can separate just the forwarding plane of SRv6 and IPv6.

E.g., what would happen to all the IPv6 mechanisms that use link-local IPv6 
addresses?

Replicating these mechanisms does not make much sense to me.

My 2c,
Sasha


Get Outlook for 
Android<https://urldefense.com/v3/__https://aka.ms/AAb9ysg__;!!NEt6yMaO-gk!HzsbTKniUOi5O0qugOI9QjUV-fzv06TpsmjMD8x0wPbs0BnNdIEeTDk9KclC7sptgzH_T9K9VovsC9Zd7PIJMn92sw$>



Juniper Business Use Only


From: Ron Bonica 
Sent: Tuesday, March 26, 2024 8:36:49 PM
To: Alexander Vainshtein 
Cc: spring@ietf.org ; Andrew Alston - IETF 
; Robert Raszuk ; Tom Herbert 
; Alvaro Retana 
Subject: [EXTERNAL] Re: [spring] Chair Review of 
draft-ietf-spring-srv6-srh-compression-11

Sasha,

Good point. In my previous email, I didn't mean suggest that we should divorce 
SRv6 from the entire suite of Internet protocols. I only meant that we should 
divorce the SRv6 forwarding plane from the IPv6 forwarding plane. BGP could 
continue to distribute SIDS exactly as is distributes MPLS service labels today.

You bring up another good point about the parallel evolution of SRv6 and IPv6. 
Yes, this is an engineering trade off. If you divorce SRv6 from IPv6, and IPv6 
develops a useful new feature, SRv6 might need to develop that feature, too. 
However, if you bind SRv6 to IPv6, SRv6 must strictly adhere to IPv6 standards, 
both now and in the future.

Which is more painful?

   Ron


Juniper Business Use Only


From: Alexander Vainshtein 
Sent: Tuesday, March 26, 2024 1:56 PM
To: Ron Bonica 
Cc: spring@ietf.org ; Andrew Alston - IETF 
; Robert Raszuk ; Tom Herbert 
; Alvaro Retana 
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


Ron and all,

I respectfully disagree with the proposal of separation of SRv6 from the 
existing IPv6.



IMHO and FWIW the most important added value of SRv6 is its ability to provide 
BGP-based overlay services without any changes in the P routers as described in 
Introduction of RFC 
9252<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9252*name-introduction__;Iw!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAcNI2nRxQ$>:



To provide SRv6 service with best-effort connectivity, the egress PE signals an 
SRv6 Service SID with the BGP overlay service route. The ingress PE 
encapsulates the payload in an outer IPv6 header where the destination address 
is the SRv6 Service SID provided by the egress PE. The underlay between the PEs 
only needs to support plain IPv6 forwarding 
[RFC8200<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8200__;!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAfT4HTjlw$>].



To me this means that SRv6 services can benefit from incremental deployment 
when new forwarding capabilities (implementation of SRv6 Endpoint Behaviors) 
would be initially available just in the relevant PEs.



And best-effort BGP-based SRv6 services would scale up much better than 
best-effort BGP-based services on top of a SR-MPLS underlay because:

  *   With SR-MPLS, the forwarding HW of the ingress PE would have to maintain 
at least one dedicated egress encapsulation information element for the local 
representation of each service instance in each egress PE of this service (the 
label stack that delivers the packet to the relevant egress PE and the label 
that identifies the relevant service in this egress PE)
  *   With SRv6, the forwarding HW of the ingress PE would have to maintain 
only a dedicated egress encapsulation information element for each local 
adjacency of this PE.

IMHO and FWIW the flex-algo approach extends the above scalability 
considerations to BGP-based SRv6 services that require some kind of traffic 
engineering.



All these advantages would be lost if SRv6 were separated from IPv6. Such 
separation would require, at the very least:

  *   HW (or FW) upgrades that would identify received SRv6 packets based on 
their new Ethertype – across the entire SRv6 network
  *   SW upgrades supporting new/modified routing protocols 

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Robert,

I wish we had accepted your initial proposal, all those years ago. Now that we 
have begun deployment, changing direction is more difficult. But experience 
teaches us that proceeding with a questionable decision because deployment has 
begun frequently contributes to the  accumulation of architectural debt.

The incremental deployment problem that you mention was solved many years ago. 
Tunnel SRv6 over something else (IPv4, IPv6, MPLS, whatever.)

Ron


Juniper Business Use Only


From: Robert Raszuk 
Sent: Tuesday, March 26, 2024 1:24 PM
To: Ron Bonica 
Cc: Tom Herbert ; Alvaro Retana ; 
Andrew Alston - IETF ; spring@ietf.org 
; Joel Halpern 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


Ron,

While I did suggest the use of new Ethertype for SRv6 in the very early days 
the killer and valid argument against it was ease of deployment. An equally 
valid argument was built in the extensibility of IPv6 protocol.

So we see the latter is an interesting one, but let's zoom on the former.

In a 1000 node network, if I want to enable SRv6 only on subset of nodes (which 
in many cases is sufficient for a lot of TE purposes)  I need to upgrade only 
those affected nodes leaving all other nodes just doing basic vanilla IPv6.

If for SRv6 encapsulation new Ethertype is used all 1000 nodes need to be 
upgraded. It will be worse then transition to IPv6 as you will then say - Oh 
Mr. Customer ... do you really need to upgrade your entire network and spend 
millions doing it - just stick to SR-MPLS :) And I know you would love to do 
that.

So I think like others say .. The ship has hit the waters. You have a choice to 
jump on it or stay on the shore.

Cheers,
Robert


On Tue, Mar 26, 2024 at 6:14 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Working Group,

Might  SRv6 progress much more quickly if we did the following:


  *
Divorce SRv6 from IPv6
  *
Give SRv6 its own ethertype
  *
Let SRv6 progress along its own evolutionary trajectory, unencumbered by IPv6 
restrictions


At very least, this divorce would end the long and painful debates regarding 
IPv6 compliance. And would it give SRv6 more degrees of freedom as it evolves,

As far as I can see, the only benefit of binding SRv6 to IPv6 is in the 
expectation that IPv6-enabled hardware won't have to change too much to support 
SRv6. This benefit might still be realized if SRv6 doesn't deviate too much 
from IPv6.

My question is not rhetorical. Maybe I am missing something, but is there any 
real benefit in continuing to bind SRRv6 to IPv6?

   Ron


Juniper Business Use Only


From: Tom Herbert mailto:t...@herbertland.com>>
Sent: Monday, March 25, 2024 3:40 PM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Andrew Alston 
- IETF ; Ron Bonica 
mailto:rbon...@juniper.net>>; 
spring@ietf.org<mailto:spring@ietf.org> 
mailto:spring@ietf.org>>; Joel Halpern 
mailto:j...@joelhalpern.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:
>
> Tom:
>
> Hi!
>
> I understand your point.
>
> I put the option out there because it came up at last week’s spring meeting 
> and it should be discussed.

Alvaro,

This seems to come back to the fundamental question: is SRv6 still
IPv6 or is it a new protocol. If it's IPv6 then it should adhere to
all the requirements and expectations of IPv6, if it's a new protocol
that is going to diverge from the standard IPv6 then maybe it needs
its own EtherType and standards development path.

Tom


>
> Thanks!
>
> Alvaro.
>
>
> On March 25, 2024 at 2:58:48 PM, Tom Herbert 
> (t...@herbertland.com<mailto:t...@herbertland.com>) wrote:
>
> On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana 
> mailto:aretana.i...@gmail.com>> wrote:
> >
> > FWIW, I agree with most of what Joel wrote. ;-)
> >
> > I see another path forward: Given that the issue is constrained to an SR 
> > domain, the draft could also point out the issues as operational/deployment 
> > considerations. Operators can then make an informed decision on whether 
> > they want to/can use C-SIDs without an SRH in their network. This path 
> > forward (or leaving it out of scope, as Joel suggests below) is something 
> > the spring WG can reach consensus on by itself (i.e., without needing to 
> > consult or agree with other WGs).
>
> Alvaro,.
>
> This wouldn't be robust and would seem to violate the &quo

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Sasha,

Good point. In my previous email, I didn't mean suggest that we should divorce 
SRv6 from the entire suite of Internet protocols. I only meant that we should 
divorce the SRv6 forwarding plane from the IPv6 forwarding plane. BGP could 
continue to distribute SIDS exactly as is distributes MPLS service labels today.

You bring up another good point about the parallel evolution of SRv6 and IPv6. 
Yes, this is an engineering trade off. If you divorce SRv6 from IPv6, and IPv6 
develops a useful new feature, SRv6 might need to develop that feature, too. 
However, if you bind SRv6 to IPv6, SRv6 must strictly adhere to IPv6 standards, 
both now and in the future.

Which is more painful?

   Ron


Juniper Business Use Only


From: Alexander Vainshtein 
Sent: Tuesday, March 26, 2024 1:56 PM
To: Ron Bonica 
Cc: spring@ietf.org ; Andrew Alston - IETF 
; Robert Raszuk ; Tom Herbert 
; Alvaro Retana 
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


Ron and all,

I respectfully disagree with the proposal of separation of SRv6 from the 
existing IPv6.



IMHO and FWIW the most important added value of SRv6 is its ability to provide 
BGP-based overlay services without any changes in the P routers as described in 
Introduction of RFC 
9252<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9252*name-introduction__;Iw!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAcNI2nRxQ$>:



To provide SRv6 service with best-effort connectivity, the egress PE signals an 
SRv6 Service SID with the BGP overlay service route. The ingress PE 
encapsulates the payload in an outer IPv6 header where the destination address 
is the SRv6 Service SID provided by the egress PE. The underlay between the PEs 
only needs to support plain IPv6 forwarding 
[RFC8200<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8200__;!!NEt6yMaO-gk!DKf6ASDKU-trvFQgfyiW5r89q7qSEz8h0gn2C_-Q7he3Yg3qXRdjuRstXBvEo179nWAGf2K3AYzqtmlWoAfT4HTjlw$>].



To me this means that SRv6 services can benefit from incremental deployment 
when new forwarding capabilities (implementation of SRv6 Endpoint Behaviors) 
would be initially available just in the relevant PEs.



And best-effort BGP-based SRv6 services would scale up much better than 
best-effort BGP-based services on top of a SR-MPLS underlay because:

  *   With SR-MPLS, the forwarding HW of the ingress PE would have to maintain 
at least one dedicated egress encapsulation information element for the local 
representation of each service instance in each egress PE of this service (the 
label stack that delivers the packet to the relevant egress PE and the label 
that identifies the relevant service in this egress PE)
  *   With SRv6, the forwarding HW of the ingress PE would have to maintain 
only a dedicated egress encapsulation information element for each local 
adjacency of this PE.

IMHO and FWIW the flex-algo approach extends the above scalability 
considerations to BGP-based SRv6 services that require some kind of traffic 
engineering.



All these advantages would be lost if SRv6 were separated from IPv6. Such 
separation would require, at the very least:

  *   HW (or FW) upgrades that would identify received SRv6 packets based on 
their new Ethertype – across the entire SRv6 network
  *   SW upgrades supporting new/modified routing protocols dedicated for SRv6 
– also across the entire SRv6 network.



From my POV, SRv6 should try to minimize its deviations from the “normal” IPv6 
(e.g., the differences in the address architecture), clearly define them and 
avoid all attempts to violate the IPv6 rules that do not belong to the 
“deviated” area.



My 2c,

Sasha




Juniper Business Use Only

From: spring  On Behalf Of Ron Bonica
Sent: Tuesday, March 26, 2024 7:14 PM
To: Tom Herbert ; Alvaro Retana 
Cc: spring@ietf.org; Andrew Alston - IETF ; Robert 
Raszuk 
Subject: [EXTERNAL] Re: [spring] Chair Review of 
draft-ietf-spring-srv6-srh-compression-11



Working Group,



Might  SRv6 progress much more quickly if we did the following:



·   Divorce SRv6 from IPv6

·   Give SRv6 its own ethertype

·   Let SRv6 progress along its own evolutionary trajectory, unencumbered 
by IPv6 restrictions



At very least, this divorce would end the long and painful debates regarding 
IPv6 compliance. And would it give SRv6 more degrees of freedom as it evolves,



As far as I can see, the only benefit of binding SRv6 to IPv6 is in the 
expectation that IPv6-enabled hardware won't have to change too much to support 
SRv6. This benefit might still be realized if SRv6 doesn't deviate too much 
from IPv6.



My question is not rhetorical. Maybe I am missing something, but is there any 
real benefit in continuing to bind S

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Working Group,

Might  SRv6 progress much more quickly if we did the following:


  *
Divorce SRv6 from IPv6
  *
Give SRv6 its own ethertype
  *
Let SRv6 progress along its own evolutionary trajectory, unencumbered by IPv6 
restrictions


At very least, this divorce would end the long and painful debates regarding 
IPv6 compliance. And would it give SRv6 more degrees of freedom as it evolves,

As far as I can see, the only benefit of binding SRv6 to IPv6 is in the 
expectation that IPv6-enabled hardware won't have to change too much to support 
SRv6. This benefit might still be realized if SRv6 doesn't deviate too much 
from IPv6.

My question is not rhetorical. Maybe I am missing something, but is there any 
real benefit in continuing to bind SRRv6 to IPv6?

   Ron


Juniper Business Use Only


From: Tom Herbert 
Sent: Monday, March 25, 2024 3:40 PM
To: Alvaro Retana 
Cc: Robert Raszuk ; Andrew Alston - IETF 
; Ron Bonica ; spring@ietf.org 
; Joel Halpern 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana  wrote:
>
> Tom:
>
> Hi!
>
> I understand your point.
>
> I put the option out there because it came up at last week’s spring meeting 
> and it should be discussed.

Alvaro,

This seems to come back to the fundamental question: is SRv6 still
IPv6 or is it a new protocol. If it's IPv6 then it should adhere to
all the requirements and expectations of IPv6, if it's a new protocol
that is going to diverge from the standard IPv6 then maybe it needs
its own EtherType and standards development path.

Tom


>
> Thanks!
>
> Alvaro.
>
>
> On March 25, 2024 at 2:58:48 PM, Tom Herbert (t...@herbertland.com) wrote:
>
> On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana  wrote:
> >
> > FWIW, I agree with most of what Joel wrote. ;-)
> >
> > I see another path forward: Given that the issue is constrained to an SR 
> > domain, the draft could also point out the issues as operational/deployment 
> > considerations. Operators can then make an informed decision on whether 
> > they want to/can use C-SIDs without an SRH in their network. This path 
> > forward (or leaving it out of scope, as Joel suggests below) is something 
> > the spring WG can reach consensus on by itself (i.e., without needing to 
> > consult or agree with other WGs).
>
> Alvaro,.
>
> This wouldn't be robust and would seem to violate the "be conservative
> in what you send clause". Punting this to the operators doesn't seem
> practical either, in an even moderately large network they wouldn't be
> able to know all the potential problems they might hit in devices.
> They're about one misconfiguration away from having to debug a rather
> unpleasant problem. For instance, if operator gets a packet trace from
> a router they would see a whole bunch of packets with bad checksums,
> but they would have no way of knowing if these were cases of segment
> routing or actually corrupted packets.
>
> Tom
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Ron Bonica]

Andrew,

Tom Herbert (copied on this message)  raised the same issue regarding another 
draft on the 6man mailing list a few months ago. I suggested that if this 
problem ever needed to be solved, it could be solved with a new Hob-by-hop 
option. This option would contain the IPv6 address of the ultimate destination, 
so the checksum could be calculated in flight.

The beauty of this option is that it can be included, when needed and excluded, 
when not needed.

It may be time to specify the new option. What do you think?


Ron


Juniper Business Use Only


From: spring  on behalf of Andrew Alston - IETF 

Sent: Monday, March 25, 2024 8:05 AM
To: spring@ietf.org 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11


[External Email. Be cautious of content]


So I’ve given a lot of thought to the checksum issue – and here is where my 
thinking is currently sitting.



Firstly – RFC8200 does not mention the word middlebox or middleware anywhere.  
Nor does RFC8200 specify anywhere that the checksum should not be verifable in 
flight.



Indeed, section 8.1 actually details how to handle extension headers as well – 
in order to make the checksum valid (Last paragraph page 27)



Now, while there are specific uses cases for in flight validation of checksums 
which I’m not at liberty to discuss here, surfice to say that they exist and 
stem from the need to verify that packet changes aren’t occuring in flight – I 
believe that’s kinda besides the point.  The point here is that as it stands, 
the draft violates RFC8200.  This leaves two options in my view a.) Either 
update 8200 – with the agreement of 6man – or pass an RFC8200 BIS through 6man.



Either way – if you are violating a standard held by another working group – 
and this does violate section 8.1 – you should be updating the standard that is 
being violated or alternatively BIS’ing it to avoid the violation.   But both 
require that 6man is in full agreement, since SPRING is not chartered to make 
updates or violate standards put forward by another working group.  Hence – my 
suggestion would be to take this to 6man and go through the process, though at 
minimum I fail to see how this cannot update RFC8200.



In fact, let me be clear here – any attempt to pass this document WITHOUT 
correct review by 6man will result in an appeal.



Thanks



Andrew






Internal All Employees

From: spring  on behalf of Francois Clad 

Date: Monday, 18 March 2024 at 17:50
To: Alvaro Retana 
Cc: SPRING WG List 
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Some people who received this message don't often get email from 
fclad.i...@gmail.com. Learn why this is 
important

CAUTION: This email has originated from a free email service commonly used for 
personal email services, please be guided accordingly especially if this email 
is asking to click links or share information.



Dear Alvaro,



We have integrated the remainder of your feedback in revision -14.



Detailed replies inline. These include your follow-up comments as well as the 
review items that we missed in the first pass.



Please let us know if you have any further feedback.



Thanks,

Francois



> ...

> > > Operational Considerations/Guidance

> > >

> > > Dhruv brought up [1] the point of providing "guidance on when to use

> > > which flavor and with which C-SID lengths". I fully agree! The

> > > document contains (mostly in §4) recommendations, for example, about

> > > LBL and C-SID lengths, even if any other value is possible. IOW, the

> > > possibilities are endless! Please provide more operational

> > > considerations on how an operator can evaluate their needs and select

> > > the appropriate flavor/value for their deployment.

> >

> > We added a paragraph providing such operational guidance in revision -12, 
> > and

> > further clarified it in revision -13.

> >

> > | SRv6 is intended for use in a variety of networks that require

> > | different prefix lengths and SID numbering spaces. Each of the two

> > | flavors introduced in this document comes with its own

> > | recommendations for Locator-Block and C-SID length, as specified in

> > | Section 4.1 and Section 4.2. These flavors are best suited for

> > | different environments, depending on the requirements of the network.

> > | For instance, larger C-SID lengths may be more suitable for networks

> > | requiring ample SID numbering space, while smaller C-SID lengths are

> > | better for compression efficiency. The two compression flavors allow

> > | the compressed segment list encoding to adapt to a range of

> > | requirements, with support for 

Re: [spring] draft-ietf-spring-srv6-srh-compression

[Ron Bonica]

Folks,

Someone raised the same objection with regard to the CRH 
Draft<https://datatracker.ietf.org/doc/html/draft-ietf-6man-comp-rtg-hdr-03>. 
Since there iss no easy solution to the problem, the authors simply 
acknowledged the issue in Section 
7<https://www.ietf.org/archive/id/draft-ietf-6man-comp-rtg-hdr-03.html#name-destination-address-transpa>
 of the draft. So, operators are warned. If you have middleboxes that verify L4 
checksums, don't deploy this technology.

You might want to add a similar section in your draft.

   Ron




Juniper Business Use Only


From: Tal Mizrahi 
Sent: Tuesday, February 6, 2024 9:46 AM
To: Andrew Alston - IETF 
Cc: Antoine FRESSANCOURT ; 
Robert Raszuk ; Ron Bonica ; 
spring@ietf.org 
Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression

[External Email. Be cautious of content]


Dear Andrew,

A couple of questions regarding the middlebox use case.

1. I am curious to know whether there are existing middleboxes that
can verify the L4 checksum for packets with an SRH.
2. Can a middlebox verify the L4 checksum of a packet with an SRH *in
compliance with RFC 8200*?
  RFC 8200 defines the pseudo-header "At the originating node" and "at
the recipient(s)", but does not say anything about middleware. Is it
implicitly assumed that the middleware is an "originating node"?

Cheers,
Tal.

On Tue, Feb 6, 2024 at 12:16 PM Andrew Alston - IETF
 wrote:
>
> I think it’s only fair to clarify my remarks – again – speaking entirely as a 
> contributor.
>
>
>
> Let’s be clear – the middlware boxes will work in most cases – except when 
> there is no SRH.
>
>
>
> The problem here is that if you apply a Micro-SID – which is imposed by 
> originating system – and have no SRH – the DA of the packet is changing along 
> the way – and the L4 checksum will be broken.  There is no way to actually 
> calculate the correct L4 checksum in flight – and in reality the originating 
> system will now need to impose a checksum that is invalid at the start for it 
> to be correct at the end – breaking end to end check summing.  This is a 
> problem.
>
>
>
> Let’s look at what 8200 says:
>
>
>
>   o  If the IPv6 packet contains a Routing header, the Destination
>
>  Address used in the pseudo-header is that of the final
>
>  destination.  At the originating node, that address will be in
>
>  the last element of the Routing header; at the recipient(s),
>
>  that address will be in the Destination Address field of the
>
>  IPv6 header.
>
>
>
> Now, in the case of no SRH – the DA address placed by the originating host – 
> is *NOT* the final DA – because of the manipulation in the middle.
>
>
>
> The reality is that middleware boxes are (unfortunately) common – especially 
> in this part of the world – they are used by state and other entities for DPI 
> and traffic control etc – and they are used for IDS purposes etc – and 
> breaking the L4 checksum in flight with no way for these boxes to calculate 
> the correct checksum – will break existing deployments – that – is a problem 
> and it needs to be addressed.  I would be quite fine if there was explicit 
> text detailing this that was explicitly approved by 6man as the originators 
> of 8200 (and a clear indication that this document updates 8200) – or 
> alternatively a -BIS to 8200.  Either way – if you break the checksum – this 
> needs explanatory text and it needs approval for 6man via a 6man Last call as 
> far as I am concerned.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
>
>
>
> Internal All Employees
>
> From: Antoine FRESSANCOURT 
> Date: Tuesday, 6 February 2024 at 12:16
> To: Andrew Alston - IETF , Robert Raszuk 
> , Ron Bonica 
> Cc: spring@ietf.org 
> Subject: RE: [spring] draft-ietf-spring-srv6-srh-compression
>
> Hello,
>
>
>
> I tend to agree with Andrew that the fact that the verification of a L4 
> checksum by a middlebox breaks is a problem. But I think this is a huge 
> problem with the middleboxes, not with SRv6.
>
>
>
> According to me, reading RFC 8200 gives rather clear guidelines with regards 
> to the computation of the L4 checksum. This checksum should be computed using 
> the destination address seen by the destination verifying the checksum. As L4 
> protocols are end to end protocols, the checksum verifier is the end point 
> destination of the packet, and not a middlebox on the path. If a middlebox 
> breaks the communication by looking at fields it should not look at, then the 
> problem is the intervention of the middlebox.
>
>
>
> B

Re: [spring] draft-ietf-spring-srv6-srh-compression

[Ron Bonica]

Folks,

Has anyone proposed a solution to the L4 checksum problem that Andrew talks 
about?

  Ron


Juniper Business Use Only


From: spring  on behalf of Andrew Alston - IETF 

Sent: Monday, February 5, 2024 5:21 AM
To: spring@ietf.org 
Subject: [spring] draft-ietf-spring-srv6-srh-compression


[External Email. Be cautious of content]


Hi All,



(In capacity as a contributor and wearing no other hats)



At this point I cannot support progression of this document until the issues 
around the L4 Checksum have been resolved.  It’s been clearly stated in other 
emails on the list that in certain circumstances the behavior described in this 
document break the L4 checksum as defined in RFC8200.  This requires an update 
to RFC8200 to fix it – and I’m not sure that spring can update 8200 absent the 
consent of 6man, which I’m not sure has been asked for, nor am I sure that a 
spring document can update something like 8200 in an area so fundamental as the 
checksum without a -BIS, which would have to be done via 6man.  The L4 checksum 
issue though is real – and it cannot simply be ignored.



I also have deep concerns that the compression document creates something that 
(in a similar way to SRv6) creates something that is completely non-conformant 
with RFC4291.  There are multiple references to this in draft-6man-sids, and 
should draft-6man-sids become an RFC I would argue that it should probably be a 
normative reference in this document – on the logic that this document relies 
on similar RFC4291 violations that srv6 itself does (and for the record, just 
because SRv6 itself violates RFC4291 as is clearly documented in 
draft-6man-sids – does not make it acceptable to do so in yet another draft 
without clear and unambiguously stating the deviations and ideally updating 
RFC4291 to allow for said deviations)



I believe these two issues alone are sufficient that to pass this document 
would create still further tensions about the relationship between SRv6 and 
IPv6 and lead to confusion.  As such – I believe these issues need to be 
adequately dealt with – and the solutions to them need to be approved by 6man 
as the working group that holds responsibility for ipv6 maintenance.



Thanks



Andrew Alston






Internal All Employees
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] A review of draft-ietf-spring-srv6-srh-compression-08

[Ron Bonica]

Adrian,

You say,

" b. draft-ietf-spring-compression-requirement has expired and perhaps
  the WG intends it to fade away now that this draft is close to
  completion."

As a co-author, I think that draft-ietf-spring-compression-requirement should 
be allowed to fade away. It has received not attention for years and I don't 
know what value it adds in 2023.

Ron



Juniper Business Use Only
-Original Message-
From: spring  On Behalf Of Adrian Farrel
Sent: Thursday, September 21, 2023 9:36 AM
To: 'SPRING WG List' 
Cc: spring-cha...@ietf.org
Subject: [spring] A review of draft-ietf-spring-srv6-srh-compression-08

[External Email. Be cautious of content]


Hi,

This review is in answer to Joel's request on the mailing list. I come to this 
document without a lot of history on SRH compression (although I had some chats 
with Cheng Li, which helped me to not embarrass myself with some of my more 
stupid questions) and I have deliberately not read any of the threads on the 
list. If my comments raise questions that have already been discussed and 
resolved, then I offer no apologies because the document needs clarity.

Ideally, a constructive review would provide suggested resolutions with 
proposed new text. Some of my recommendations, however, would constitute 
significant rewriting (which I haven't signed up for). I'm not sure whether the 
authors will be enthusiastic to make such wholesale changes, but I offer up the 
ideas in any case.

The big question was whether I believed I could create an interoperable 
implementation from this document. I think I mainly could. That is, for the 
core features and avoiding the corner cases, I think it would probably work out 
of the box. For example, using 32 bit LNFs and running in a domain where all 
nodes were capable of just one of the C-SIDs, and so on. I am less convinced 
that the more tricky corner cases would work without some careful interop 
testing and bug fixing, so out-of-the-box deployments might be unwise. I am 
also pretty sure that diagnostics on a broken system would be hard, but I think 
that any problems would be consistent (all traffic on an SR path is not 
delivered to the right
place) which makes diagnostics a bit easier.

I did find a lot of minor points (shown below). This is very probably caused by 
the authors being "too close to the problem" such that they know what they 
meant even if the reader is not so sure. Hopefully, some polish will sort this 
out.

The more major points don't seem (to me) to be show-stoppers, but they do need 
to be resolved.

The volume of points I have raised probably means that I have missed quite a 
lot as well.

There's a lot of work here, and I am not sure that I am signed up to review 
fixes or to debate the ins and outs of each point. Similarly, I didn't commit 
to a further review of the cleaned-up document to see whether I can find 
additional issues. I would, however, be happy to clarify anything I have said.

Cheers,
Adrian

===

0. Please get into the habit of running idnits before posting a new
   revision.

   == Missing Reference: 'RFC8200' is mentioned on line 996, but not
   defined

1. Please expand "SRH" in the document name.

2. Please expand "SR" in the Abstract.

3. The Abstract and Introduction say "a compressed SRv6 Segment-List
   encoding", but it seems that this document describes two such
   encodings. Perhaps, "...which enable compression of the Segment List
   in the Segment Routing Header (SRH)."

4. It would be nice if the Abstract gave a clue as to why the Segment
   List needs to be compressed. For example, "to enable more entries in
   the Segment List without causing excessive growth in the size of the
   packet header."

5. Please decide whether "Segment List" or "Segment-List" or "segment
   list" and fix it in the whole document.

6. In the Introduction. s/segment identifier/Segment Identifier/

7. Decide between "Segment Routing Header" and "Segment Routing header"
   and fix the whole document.

8. The motivation for this draft is indicated in the Introduction with
   a reference to draft-srcompdt-spring-compression-requirement. A
   few things:
   a. This draft was replaced by draft-ietf-spring-compression-
  requirement two years ago.
   b. draft-ietf-spring-compression-requirement has expired and perhaps
  the WG intends it to fade away now that this draft is close to
  completion.
   c. If you don't want to set out more details of the motivation in
  this document (which would be fine) then I think the reference to
  this draft needs to be normative - without reading it, I cannot
  know why this work exists and whether I need to implement it. But,
  considering #b, you might find it easier to add a few lines to
  summarise the motivation and drop the reference.

9. Section 2 has...

|  This document leverages the terms defined in [RFC8402], [RFC8754],
| 

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Ron Bonica]

Brian, Tony,

You are both right! The following are possible solutions:

1) encoding the layer-3 protocol in the Ethertype (just as we have always done)
2) encoding the layer-3 protocol in the IPv6 address (as proposed recently)

Solution #1 is hard to deploy but maintains operability. Solution #2 is easy to 
deploy but hurts operability.

So, we ask ourselves when we want to pay the price? During deployment? For 
years after deployment?

   Ron


-Original Message-
From: Brian E Carpenter 
Sent: Saturday, April 1, 2023 4:29 PM
To: Tony Przygienda 
Cc: Ron Bonica ; Krzysztof Szarkowicz 
; Kireeti Kompella ; 
spring@ietf.org; int-a...@ietf.org; Andrew Alston - IETF 

Subject: Re: [Int-area] [spring] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

[External Email. Be cautious of content]


Tony,

On 02-Apr-23 05:53, Tony Przygienda wrote:
> ?
>
> I heard the argument that IPv6 address space is large and "easy to carve up 
> to mean other things" since about as long IPv6 started to gain traction. The 
> wisdom of that has been thankfully so far questioned. BIER was also 
> approached by people who hoped we would create a precedent by taking a /8 or 
> /16 or something and use the rest of bits to stick bitmasks in. Expediency 
> overriding architecture and all that usual jazz ...

I have all kinds of angst about using magic bit patterns in IPv6 addresses to 
convey semantics. Addresses are for getting packets from one end to other, 
period. However, my main interest is to prevent SRV6 SIDs doing any kind of 
damage to the universal deployment of IPv6. From that point of view, a new 
Ethertype would be great because it automatically prevents SRV6 SIDs deployment 
on the Internet rather than within limited domains.

But that doesn't affect what I said: *deploying* a new Ethertype is much, much 
harder than deploying draft-ietf-6man-sids.

>
> Yes, it's easy to "quickly deploy" and taken to the bitter conclusion we'll 
> stop having a decently economic, secure and debuggable IP forwarding path, 
> instead we end up building IP host address firewall scanning things into 
> layer 4 to find violations in complex constructs masquerading under addresses 
> and IP "extension headers" and build lots of "kind of limited but not so 
> limited and kind of secur'ish domains". Firewalls have their place but 
> routers are not firewalls.

I don't see where layer 4 comes in. SRV6 adds semantics to layer 3. Layer 3 
ACLs have existed much longer than firewalls. draft-ietf-6man-sids enables the 
non-SRV6 Internet to drop SRV6 SIDs traffic without any kind of DPI, exactly as 
a new Ethertype would.

Regards
Brian

>
> -- tony
>
> On Fri, Mar 31, 2023 at 9:00 PM Brian E Carpenter 
> mailto:brian.e.carpen...@gmail.com>> wrote:
>
> On 01-Apr-23 06:18, Ron Bonica wrote:
>  > On second thought, if we had the new ethertype, we wouldn’t need the 
> new /16!
>  >
>  > They serve the same function
>
> However, a new special-purpose prefix is rather trivial to deploy 
> compared with a new Ethertype.
>
>  Brian
>
>  >
>  >
>   Ron
>  >
>  > *From:* Ron Bonica
>  > *Sent:* Friday, March 31, 2023 1:05 PM
>  > *To:* Krzysztof Szarkowicz  <mailto:40juniper@dmarc.ietf.org>>; Kireeti Kompella 
> mailto:kireeti.i...@gmail.com>>
>  > *Cc:* Adrian Farrel  <mailto:adr...@olddog.co.uk>>; Andrew Alston - IETF 
>  <mailto:40liquid.t...@dmarc.ietf.org>>; int-a...@ietf.org 
> <mailto:int-a...@ietf.org>; spring@ietf.org <mailto:spring@ietf.org>; Dr. 
> Tony Przygienda mailto:tonysi...@gmail.com>>
>  > *Subject:* RE: [spring] [Int-area] FW: New Version Notification for 
> draft-raviolli-intarea-trusted-domain-srv6-00.txt
>  >
>  > +1
>  >
>  > If we allocate a /16 for SRv6 USIDs, as proposed in 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt__;!!NEt6yMaO-gk!BiTuIcxt0Ilyt3xUm8Pm49DTBXGfLjUClSHBUzaSKbUH2go-4awqdPhtvHoUFKIT4YxuCNmBrQPF-ViHX9JRxTWX7eI$
>   
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt__;!!NEt6yMaO-gk!BiTuIcxt0Ilyt3xUm8Pm49DTBXGfLjUClSHBUzaSKbUH2go-4awqdPhtvHoUFKIT4YxuCNmBrQPF-ViHX9JRxTWX7eI$
>  > 
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt__;!!NEt6yMaO-gk!BiTuIcxt0Ilyt3xUm8Pm49DTBXGfLjUClSHBUzaSKbUH2go-4awqdPhtvHoUFKIT4YxuCNmBrQPF-ViHX9JRxTWX7eI$
>   
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/dra

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Ron Bonica]

On second thought, if we had the new ethertype, we wouldn’t need the new /16!

They serve the same function

Ron


From: Ron Bonica
Sent: Friday, March 31, 2023 1:05 PM
To: Krzysztof Szarkowicz ; Kireeti 
Kompella 
Cc: Adrian Farrel ; Andrew Alston - IETF 
; int-a...@ietf.org; spring@ietf.org; 
Dr. Tony Przygienda 
Subject: RE: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

+1

If we allocate a /16 for SRv6 USIDs, as proposed in 
https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt,
we can allow that prefix only when the new ethertype is used.


  Ron

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, March 29, 2023 5:30 AM
To: Kireeti Kompella mailto:kireeti.i...@gmail.com>>
Cc: Adrian Farrel mailto:adr...@olddog.co.uk>>; Andrew 
Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>;
 int-a...@ietf.org<mailto:int-a...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; Dr. Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

[External Email. Be cautious of content]

SRv6 packet might have SRH, but might not have SRH. Especially with uSID, you 
can craft a decent SR-TE SRv6 packet without SRH. So I think, Kireetis’ 
comments should apply to all SRv6 packets (with/without SRH).

—
Krzysztof

On 2023 -Mar-29, at 17:57, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Though I would like to cheer for Kireeti's 2. as well I think the point of 
SHOULD is more realistic (for now) as Joel points out ...

As to ethertype, I think grown-ups in the room were since long time drily 
observing that a new IP version would have been appropriate after enough 
contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
 were performed with drafts whose authors' list length sometimes rivaled pages 
of content ;-)  I think this ship has sailed and that's why after some 
discussions with Andrew we went the ether type route as more realistic. 
Additionally, yes, lots encaps (not encodings) carrying SRv6 should get new 
codepoints if we are really serious about trusted domains here.

And folks who went the MPLS curve know that none of this is new, same curve was 
walked roughly (though smoother, no'one was tempted to "hide label stack in 
extension headers" ;-) and it would go a long way if deploying secure SRv6 
becomes as simple as *not* switching on "address family srv6" on an interface 
until needed and then relying on BGP-LU (oops ;-) to build according lookup 
FIBs for SRv6 instead of going in direction of routers becoming massive 
wildcard matching and routing header processing firewalls ...

--- tony



On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella 
mailto:kireeti.i...@gmail.com>> wrote:
On Mar 28, 2023, at 11:24, Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:

[Spring cc’ed because, well, you know, SR. I wonder whether 6man and 6ops 
should care as well.]

SPRING cc’ed because, you know, replying to Adrian’s email.  Agree that 6man 
and 6ops [sh|w]ould be interested.

tl;dr
I think this is a good initiative and worth discussion. Thanks
for the draft.

Agree.  In particular:
1. There is an acknowledged security problem. Might be worth summarizing, as it 
is central to this draft, but an example is in rfc 8402/section 8. Section 3 of 
this draft (“The SRv6 Security Problem”) doesn’t actually describe the security 
problem; Section 5 does, briefly.

2. The solution (using a new EtherType, SRv6-ET) is a good one.  It’s sad that 
this wasn’t done from the get-go, as the solution is a bit “evil bit”-ish.  I’d 
prefer to see ALL SRv6 packets (i.e., those containing SRH) use SRv6-ET.  
Boundary routers SHOULD drop packets with SRv6-ET that cross the boundary in 
either direction; all routers MUST drop packets with SRH that don’t have 
SRv6-ET. Yeah, difficult, but the added security is worth it.

3. Ease of secure deployment is a major consideration; this draft is a big step 
in that direction.

4. As Adrian said, several nits.  Will send separately to authors.

Kireeti


___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!GGgCymh1gmvxc7ibG9cWpBOm73ewlZbNJjAA4xw8KNZFBMd9ROvcdT5tCSooD-OCMYFWheicbBfDrzfTkoY7bGn7W65rg0E$>
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring



Juniper Business Use Only
___

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Ron Bonica]

+1

If we allocate a /16 for SRv6 USIDs, as proposed in 
https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt,
we can allow that prefix only when the new ethertype is used.


  Ron

From: spring  On Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, March 29, 2023 5:30 AM
To: Kireeti Kompella 
Cc: Adrian Farrel ; Andrew Alston - IETF 
; int-a...@ietf.org; spring@ietf.org; 
Dr. Tony Przygienda 
Subject: Re: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

[External Email. Be cautious of content]

SRv6 packet might have SRH, but might not have SRH. Especially with uSID, you 
can craft a decent SR-TE SRv6 packet without SRH. So I think, Kireetis’ 
comments should apply to all SRv6 packets (with/without SRH).

—
Krzysztof


On 2023 -Mar-29, at 17:57, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Though I would like to cheer for Kireeti's 2. as well I think the point of 
SHOULD is more realistic (for now) as Joel points out ...

As to ethertype, I think grown-ups in the room were since long time drily 
observing that a new IP version would have been appropriate after enough 
contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
 were performed with drafts whose authors' list length sometimes rivaled pages 
of content ;-)  I think this ship has sailed and that's why after some 
discussions with Andrew we went the ether type route as more realistic. 
Additionally, yes, lots encaps (not encodings) carrying SRv6 should get new 
codepoints if we are really serious about trusted domains here.

And folks who went the MPLS curve know that none of this is new, same curve was 
walked roughly (though smoother, no'one was tempted to "hide label stack in 
extension headers" ;-) and it would go a long way if deploying secure SRv6 
becomes as simple as *not* switching on "address family srv6" on an interface 
until needed and then relying on BGP-LU (oops ;-) to build according lookup 
FIBs for SRv6 instead of going in direction of routers becoming massive 
wildcard matching and routing header processing firewalls ...

--- tony



On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella 
mailto:kireeti.i...@gmail.com>> wrote:
On Mar 28, 2023, at 11:24, Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:

[Spring cc’ed because, well, you know, SR. I wonder whether 6man and 6ops 
should care as well.]

SPRING cc’ed because, you know, replying to Adrian’s email.  Agree that 6man 
and 6ops [sh|w]ould be interested.


tl;dr
I think this is a good initiative and worth discussion. Thanks
for the draft.

Agree.  In particular:
1. There is an acknowledged security problem. Might be worth summarizing, as it 
is central to this draft, but an example is in rfc 8402/section 8. Section 3 of 
this draft (“The SRv6 Security Problem”) doesn’t actually describe the security 
problem; Section 5 does, briefly.

2. The solution (using a new EtherType, SRv6-ET) is a good one.  It’s sad that 
this wasn’t done from the get-go, as the solution is a bit “evil bit”-ish.  I’d 
prefer to see ALL SRv6 packets (i.e., those containing SRH) use SRv6-ET.  
Boundary routers SHOULD drop packets with SRv6-ET that cross the boundary in 
either direction; all routers MUST drop packets with SRH that don’t have 
SRv6-ET. Yeah, difficult, but the added security is worth it.

3. Ease of secure deployment is a major consideration; this draft is a big step 
in that direction.

4. As Adrian said, several nits.  Will send separately to authors.

Kireeti


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] uSID and destination options

[Ron Bonica]

Darren,

Yes, the SR ingress node would need to add an SRH whenever the packet includes 
an extension header that needs to be processed at the packet's ultimate 
destination only.

This would be an odd routing header as it would include no routing information 
whatsoever.

You might want to document this along with the other case in which you need an 
SRH that contains no routing information. This is the case where:

  *   The entire SR Path is represented in the IPv6 Destination Address by a 
single C-SID container
  *   The SRH does not contain any SIDs
  *   The SRH is required to carry the flag, tag and TLV fields

Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Wednesday, November 17, 2021 3:27 PM
To: Ron Bonica ; spring@ietf.org; 6...@ietf.org
Subject: Re: uSID and destination options

[External Email. Be cautious of content]

Hi Ron, I'm glad we read that the same.

As usual for SRv6, the SR source needs to decide how to build the IPv6 
extension header chain. With current text, when extension headers are required 
to be processed at the ultimate segment, the SR source would need to add an SRH.

Would you agree?

The pseudocode could be modified such that the SR source adds an SRH only when 
it wants a dest-opt header to be processed at each segment endpoint. Section 
4.1.1 would state the pseudocode is invoked when processing any header type 
other than HBH or dest-opt (vs just upper layer header).

Darren


On 2021-11-16, 1:14 PM, "Ron Bonica" 
mailto:rbonica=40juniper@dmarc.ietf.org>>
 wrote:

Hi Darren,

That's my reading, too. But this leads us to additional questions:

- How do we encode destination options that need to be processed at the 
SR Path egress node only?

- How do we encode the Fragment Option?

- How do we encode the ESP option?
In these cases, do we need an SRH to indicate that the extension headers that 
follow it are to be processed by the SR path egress node only? Would that SRH 
carry any routing information at all?


Ron




Juniper Business Use Only
From: Darren Dukes (ddukes) 
mailto:ddukes=40cisco@dmarc.ietf.org>>
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; 
spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: uSID and destination options

[External Email. Be cautious of content]

Hi Ron, my read of section 4.1.1 of the draft is the dest opt in your example 
packet would be processed at every segment endpoint.

Darren

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: Monday, November 15, 2021 2:12 PM
To: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: [spring] uSID and destination options

C-SID authors,

Consider an SRv6 packet that contains:


* An outer IPv6 header

* A Destination Options Header

* IPv4 payload

The packet does not contain an SRH. However, the Destination Address field  in 
the outer IPv6 header contains a C-SID container and the C-SID container 
contains two or more C-SIDs.

Where are the destination options processed? The following are possible answers 
to this question:


* At every segment endpoint node

* At the SR path egress node

 Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[Ron Bonica]

Tianran,

I will state the case a little more bluntly. You need a method of invoking 
AltMark behavior:

- at each hop along a packet's deliver path
- at segment endpoints only
- at the ultimate destination node only

You have already defined the AltMark Option that can be included in:

- A Hop-by-hop extension header (processed at each hop along a packet's 
delivery path)
- A Destination Options header that precedes a routing header (processed at 
segment endpoints only)
- A Destination Options header that follows a routing header ( processed at the 
ultimate destination only)

You don't need anything else. 

  Ron



Juniper Business Use Only

-Original Message-
From: Tianran Zhou  
Sent: Tuesday, November 16, 2021 9:08 PM
To: Ron Bonica ; Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]


Hi Ron,

Your both questions are too generic. I cannot answer, I do not want to boil the 
ocean.
In addition, the SRH TLV proposal is not relevant to both of your questions.
The proposal is for a specific scenario.
This document would update the AltMark application only for SRv6. This means 
that:
• in case of SRv6, AltMark can be applied through SRH TLV, • for all the other 
cases with IPv6 data plane, the use of the HbH and DOH is the only choice to 
carry AltMark data fields.

Follow your thoughts, maybe there is no need for HbH and DoH two EHs.
With HbH, we can configure each intermediate node not to process the further 
options, then only destination node process. This is the same function as in 
DoH.
With DoH, we can configure each intermediate node to process the DoH by force, 
then every node along the path can process. This is the same function as in HbH.

Regards,
Tianran

-Original Message-
From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Wednesday, November 17, 2021 1:00 AM
To: Tianran Zhou ; Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Tianran,

Should the IETF standardize two methods of encoding the same information 
because some networks have not deployed the older method? (yes/no)

Should the IETF standardize two methods of encoding the same information 
because some hardware platforms have never implemented the older method? (yes / 
no)

If the answer to either question is "yes", please explain why?

If the answer to both questions is "no", please explain why the SRH TLV for 
Alternate Marking is needed.


 Ron



Juniper Business Use Only

-Original Message-
From: Tianran Zhou 
Sent: Monday, November 15, 2021 8:03 PM
To: Ron Bonica ; Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]


Hi Ron,
Please see my reply in line.

Thanks,
Tianran

-----邮件原件-
发件人: Ron Bonica [mailto:rbon...@juniper.net]
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou ; Tom Herbert 
抄送: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

The SRH TLV for Alternate Marking isn't needed because its meaning is identical 
to the AltMark Option when it appears in a Destination Options Header that 
precedes the SRH.

Arguments regarding the HBH are orthogonal to this issue. The HBH is processed 
at every node along a packet's deliver path, while the Destination Options 
header that precedes the SRH is processed " by the first destination that 
appears in the IPv6 Destination Address field plus subsequent destinations 
listed in the Routing header.

ZTR> This is clear to me. But this is not my point to propose the SRH TLV 
method.

Arguments regarding whether a complete IPv6 implementation must support the 
Destination Options header have already been settled by RFC 8200.

ZTR> I am sorry, I do not understand what do you mean hear. Could you please 
give more hint?

Arguments about whether it is easier to parse two smaller extension headers or 
one larger extension headers are not appropriate in the IETF, because they are 
platform dependent.

ZTR> My point is not about parsing two smaller EH vs. one larger EH. My point 
is the deployment when a network that support SRH but not support other EHs.



  Ron







Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; 

Re: [spring] uSID and destination options

[Ron Bonica]

Hi Darren,

That's my reading, too. But this leads us to additional questions:

  *   How do we encode destination options that need to be processed at the SR 
Path egress node only?
  *   How do we encode the Fragment Option?
  *   How do we encode the ESP option?
In these cases, do we need an SRH to indicate that the extension headers that 
follow it are to be processed by the SR path egress node only? Would that SRH 
carry any routing information at all?


Ron




Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Tuesday, November 16, 2021 8:31 AM
To: Ron Bonica ; spring@ietf.org; 6...@ietf.org
Subject: Re: uSID and destination options

[External Email. Be cautious of content]

Hi Ron, my read of section 4.1.1 of the draft is the dest opt in your example 
packet would be processed at every segment endpoint.

Darren

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: Monday, November 15, 2021 2:12 PM
To: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: [spring] uSID and destination options

C-SID authors,

Consider an SRv6 packet that contains:


  *   An outer IPv6 header
  *   A Destination Options Header
  *   IPv4 payload

The packet does not contain an SRH. However, the Destination Address field  in 
the outer IPv6 header contains a C-SID container and the C-SID container 
contains two or more C-SIDs.

Where are the destination options processed? The following are possible answers 
to this question:


  *   At every segment endpoint node
  *   At the SR path egress node

 Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[Ron Bonica]

Tianran,

Should the IETF standardize two methods of encoding the same information 
because some networks have not deployed the older method? (yes/no)

Should the IETF standardize two methods of encoding the same information 
because some hardware platforms have never implemented the older method? (yes / 
no)

If the answer to either question is "yes", please explain why?

If the answer to both questions is "no", please explain why the SRH TLV for 
Alternate Marking is needed.


 Ron



Juniper Business Use Only

-Original Message-
From: Tianran Zhou  
Sent: Monday, November 15, 2021 8:03 PM
To: Ron Bonica ; Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]


Hi Ron,
Please see my reply in line.

Thanks,
Tianran

-----邮件原件-
发件人: Ron Bonica [mailto:rbon...@juniper.net]
发送时间: 2021年11月16日 6:20
收件人: Tianran Zhou ; Tom Herbert 
抄送: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
主题: RE: [spring] A question for draft-fz-spring-srv6-alt-mark

Folks,

The SRH TLV for Alternate Marking isn't needed because its meaning is identical 
to the AltMark Option when it appears in a Destination Options Header that 
precedes the SRH.

Arguments regarding the HBH are orthogonal to this issue. The HBH is processed 
at every node along a packet's deliver path, while the Destination Options 
header that precedes the SRH is processed " by the first destination that 
appears in the IPv6 Destination Address field plus subsequent destinations 
listed in the Routing header.

ZTR> This is clear to me. But this is not my point to propose the SRH TLV 
method.

Arguments regarding whether a complete IPv6 implementation must support the 
Destination Options header have already been settled by RFC 8200.

ZTR> I am sorry, I do not understand what do you mean hear. Could you please 
give more hint?

Arguments about whether it is easier to parse two smaller extension headers or 
one larger extension headers are not appropriate in the IETF, because they are 
platform dependent.

ZTR> My point is not about parsing two smaller EH vs. one larger EH. My point 
is the deployment when a network that support SRH but not support other EHs.



  Ron







Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]


Hi Tom,

Firstly, the proposed solution follows the same logic as RFC8200, as in your 
text. So I do not see any problem. We just find another away to "ignore the 
options".
" RFC8200 relaxed the requirement for all nodes to process HBH options and 
acknowledged that this is reality. From an application perspective, if the TLVs 
can't be processed in a "fast path" it is best to ignore the options."

Secondly, I agree with the complexity of processing TLV. But we have already 
implemented the function with line rate. So the "core problem" from my 
perspective is how to deploy it.

We are always on the way to performance optimization. I've read your draft, and 
your solution is very interesting.

Best,
Tianran

-Original Message-
From: Tom Herbert [mailto:t...@herbertland.com]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou 
Cc: Joel M. Halpern ; 
draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

On Wed, Nov 10, 2021 at 10:48 PM Tianran Zhou  wrote:
>
> Hi Tom,
>
> Please see my reply below.
>
> Best,
> Tianran
>
> -邮件原件-
> 发件人: Tom Herbert [mailto:t...@herbertland.com]
> 发送时间: 2021年11月11日 2:32
> 收件人: Tianran Zhou 
> 抄送: Joel M. Halpern ; 
> draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
> 主题: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
>
> On Tue, Nov 9, 2021 at 7:41 PM Tianran Zhou  wrote:
> >
> > Hi Joel,
> >
> > I do not need to assume a device that support SRH will support this new TLV.
> > We only assume the device that do not support this new TLV can ignore and 
> > bypass the packet, not to drop.
> > I see text from RFC8754 section 2.1.
> > " all TLVs are ignored unless local configuration indicates otherwise "
> > " Thus, TLV and HMAC support  is optional for any implementation "
> > " Type Length Value (TLV) entr

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[Ron Bonica]

Folks,

The  SRH TLV for Alternate Marking isn't needed because its meaning is 
identical to the AltMark Option when it appears in a Destination Options Header 
that precedes the SRH. 

Arguments regarding the HBH are orthogonal to this issue. The HBH is processed 
at every node along a packet's deliver path, while the Destination Options 
header that precedes the SRH is processed " by the first destination that 
appears in the IPv6 Destination Address field plus subsequent destinations 
listed in the Routing header.

Arguments regarding whether a complete IPv6 implementation must support the 
Destination Options header have already been settled by RFC 8200.

Arguments about whether it is easier to parse two smaller extension headers or 
one larger extension headers are not appropriate in the IETF, because they are 
platform dependent.



  Ron







Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Tianran Zhou
Sent: Friday, November 12, 2021 3:56 AM
To: Tom Herbert 
Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

[External Email. Be cautious of content]


Hi Tom,

Firstly, the proposed solution follows the same logic as RFC8200, as in your 
text. So I do not see any problem. We just find another away to "ignore the 
options".
" RFC8200 relaxed the requirement for all nodes to process HBH options and 
acknowledged that this is reality. From an application perspective, if the TLVs 
can't be processed in a "fast path" it is best to ignore the options."

Secondly, I agree with the complexity of processing TLV. But we have already 
implemented the function with line rate. So the "core problem" from my 
perspective is how to deploy it.

We are always on the way to performance optimization. I've read your draft, and 
your solution is very interesting.

Best,
Tianran

-Original Message-
From: Tom Herbert [mailto:t...@herbertland.com]
Sent: Friday, November 12, 2021 1:05 AM
To: Tianran Zhou 
Cc: Joel M. Halpern ; 
draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark

On Wed, Nov 10, 2021 at 10:48 PM Tianran Zhou  wrote:
>
> Hi Tom,
>
> Please see my reply below.
>
> Best,
> Tianran
>
> -邮件原件-
> 发件人: Tom Herbert [mailto:t...@herbertland.com]
> 发送时间: 2021年11月11日 2:32
> 收件人: Tianran Zhou 
> 抄送: Joel M. Halpern ; 
> draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org
> 主题: Re: [spring] A question for draft-fz-spring-srv6-alt-mark
>
> On Tue, Nov 9, 2021 at 7:41 PM Tianran Zhou  wrote:
> >
> > Hi Joel,
> >
> > I do not need to assume a device that support SRH will support this new TLV.
> > We only assume the device that do not support this new TLV can ignore and 
> > bypass the packet, not to drop.
> > I see text from RFC8754 section 2.1.
> > " all TLVs are ignored unless local configuration indicates otherwise "
> > " Thus, TLV and HMAC support  is optional for any implementation "
> > " Type Length Value (TLV) entries contain OPTIONAL information that may
> >be used by the node identified in the Destination Address (DA) of the
> >packet. "
> > " The Length field of the TLV is used to skip the TLV while inspecting
> >the SRH in case the node doesn't support or recognize the Type. "
> >
> > My understanding on SRH can support my assumption.
>
> Tianran,
>
> RFC8200 allows intermediate nodes to ignore TLVs in HBH options, and I did 
> propose allowing intermediate destinations to ignore destination options 
> before the routing header in draft-herbert-ipv6-update-opts.
>
> ZTR> It is true, but this is another story. RFC8200 is new, while RFC2460 has 
> been widely deployed. The industry need time to evolve. I talked about the 
> reality. The new proposal is motivated by the real deployment.
>
> But allowing nodes to ignore TLVs only mitigates the problems of packet loss 
> in the presence of TLVs; the obvious purpose of defining a new TLV is that it 
> _will_ be processed, lest the host sender is just wasting cycles and 
> bandwidth sending bits no one looks at. If all implementations of SRH ignore 
> TLVs then defining the TLV is pointless (AFAIK only Linux and maybe VPP 
> software implementations support SRH TLVs). For the purposes of actually 
> processing a TLV, like alt mark, I still don't see any advantage to putting 
> this in SRH as opposed to Destination options or HBH options.
>
> ZTR> We consider the incremental deployment case, or the deployment with 
> multi-vendors. That means the supportive node could process SRH TLV well, 
> while the non-supportive node could still transit. This is still valuable for 
> operators to narrow down the scope when packet loss happens. This could also 
> encourage the new tech development and deployment. I 

[spring] uSID and destination options

[Ron Bonica]

C-SID authors,

Consider an SRv6 packet that contains:


  *   An outer IPv6 header
  *   A Destination Options Header
  *   IPv4 payload

The packet does not contain an SRH. However, the Destination Address field  in 
the outer IPv6 header contains a C-SID container and the C-SID container 
contains two or more C-SIDs.

Where are the destination options processed? The following are possible answers 
to this question:


  *   At every segment endpoint node
  *   At the SR path egress node

 Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Robert,

Please read the Metric for this requirement:


  *   Metric: The utilization metric (U) records whether a proposal utilizes 
the SRv6 specifications.
  *
A proposal can use 8404, 8986, etc and still change the SRv6 data plane.

 Ron





Juniper Business Use Only
From: Robert Raszuk 
Sent: Tuesday, October 26, 2021 4:10 PM
To: Ron Bonica 
Cc: John Scudder ; 
draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org; spring@ietf.org
Subject: Re: [spring] "This solution does not require any SRH data plane 
change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]

4.  SRv6 Specific Requirements

4.1.  SRv6 Based

   Description: A solution to compress SRv6 SID Lists SHOULD be based on
   the SRv6 architecture, control plane and data plane.  The compression
   solution MAY be based on a different data plane and control plane,
   provided that it derives sufficient benefit.

It is clearly a requirement. It is not an exclusive requirement, but that does 
not make it of any less importance as evaluation criteria. Analysis draft 
provides comparison table in section 3.1

But please let's not derail this thread as I provided a specific question to 
John.

On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:

Many thx,
R.
Robert,

Which requirement was that?

Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Robert Raszuk
Sent: Tuesday, October 26, 2021 3:41 PM
To: John Scudder mailto:j...@juniper.net>>
Cc: 
draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org<mailto:draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org>;
 spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] "This solution does not require any SRH data plane 
change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]

Hello John,

May I inquire what was not definitive as part of my answer ?

Please observe that below documents which are product of this WG go in depth to 
evaluate compression against the requirement not to change SRv6 data plane:

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrQcnZRJk$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrft1hBsN$>

Would your enquiry be satisfied if the draft in question s/SRH data plane/SRv6 
data plane/ ?

Kind regards,
Robert



On Tue, Oct 26, 2021 at 7:55 PM John Scudder 
mailto:j...@juniper.net>> wrote:
(For clarity: I'm not wearing any hats other than "WG contributor".)

Hi All,

Since there hasn't been any definitive answer from the authors, nor any update 
to the draft to address the issue, and given that the disputed statement seems 
to be an important premise for evaluation of the fitness of the draft for 
adoption (at least, the authors considered it fundamental enough to put in the 
abstract): I'm opposed to adoption of the draft until this question has been 
settled, or at least meaningfully addressed.

Regards,

-John

P.S.: I will also follow up to the main adoption thread to assist with issue 
tracking.

> On Oct 13, 2021, at 6:28 PM, John Scudder 
> mailto:40juniper@dmarc.ietf.org>> wrote:
>
>
> Hi Folks,
>
> I'm struggling with the claim repeated throughout the beginning of 
> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that 
> "this solution does not require any SRH data plane change".
>
> I'm not aware of a standardized formal definition of "data plane", it seems 
> to follow Justice Stewart's maxim of "I know it when I see it". However, 
> here's an attempt, cribbed from some Washington University course slides: a 
> "local, per-router function that determines how a datagram arriving on a 
> router input port is forwarded to a router output port". Seems reasonable.
>
> I also am not aware of a standardized formal definition of the term "SRH data 
> plane", in fact this draft, its predecessors, some associated blog posts, and 
> Clarence's dissertation, are the only places a search finds the phrase (but 
> it's not formally defined in any of them). So I'm just going to assume it 
> means the data plane, as applied to packets that include an SRH. (I'm not 
> sure why we should disregard packets that are encoded using NEXT-C-SID that 
> om

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Robert,

Which requirement was that?

Ron




Juniper Business Use Only
From: spring  On Behalf Of Robert Raszuk
Sent: Tuesday, October 26, 2021 3:41 PM
To: John Scudder 
Cc: draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org; spring@ietf.org
Subject: Re: [spring] "This solution does not require any SRH data plane 
change" in draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]

Hello John,

May I inquire what was not definitive as part of my answer ?

Please observe that below documents which are product of this WG go in depth to 
evaluate compression against the requirement not to change SRv6 data plane:

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

Would your enquiry be satisfied if the draft in question s/SRH data plane/SRv6 
data plane/ ?

Kind regards,
Robert



On Tue, Oct 26, 2021 at 7:55 PM John Scudder 
mailto:j...@juniper.net>> wrote:
(For clarity: I'm not wearing any hats other than "WG contributor".)

Hi All,

Since there hasn't been any definitive answer from the authors, nor any update 
to the draft to address the issue, and given that the disputed statement seems 
to be an important premise for evaluation of the fitness of the draft for 
adoption (at least, the authors considered it fundamental enough to put in the 
abstract): I'm opposed to adoption of the draft until this question has been 
settled, or at least meaningfully addressed.

Regards,

-John

P.S.: I will also follow up to the main adoption thread to assist with issue 
tracking.

> On Oct 13, 2021, at 6:28 PM, John Scudder 
> mailto:40juniper@dmarc.ietf.org>> wrote:
>
>
> Hi Folks,
>
> I'm struggling with the claim repeated throughout the beginning of 
> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that 
> "this solution does not require any SRH data plane change".
>
> I'm not aware of a standardized formal definition of "data plane", it seems 
> to follow Justice Stewart's maxim of "I know it when I see it". However, 
> here's an attempt, cribbed from some Washington University course slides: a 
> "local, per-router function that determines how a datagram arriving on a 
> router input port is forwarded to a router output port". Seems reasonable.
>
> I also am not aware of a standardized formal definition of the term "SRH data 
> plane", in fact this draft, its predecessors, some associated blog posts, and 
> Clarence's dissertation, are the only places a search finds the phrase (but 
> it's not formally defined in any of them). So I'm just going to assume it 
> means the data plane, as applied to packets that include an SRH. (I'm not 
> sure why we should disregard packets that are encoded using NEXT-C-SID that 
> omit the SRH, but let's overlook that for now.)
>
> If this solution does not require any SRH data plane change, presumably it 
> would be true that if I take a packet that includes an SRH and place within 
> it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, then 
> that packet would be able to successfully traverse a network of routers that 
> support plain vanilla RFC 8754. That is, it would arrive at its first hop 
> router which according to a local, per-router function, would determine how 
> to take the datagram arriving on the router input port and forward it to (the 
> correct) router output port. Then that process would be repeated across the 
> rest of the network.
>
> But that is patently incorrect: when it's delivered to the first hop, the 
> plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID 
> behavior, and forwarding to the next hop will fail. It seems that a different 
> local, per-router function is required (in fact, the local, per-router 
> function defined in the draft) in order for the forwarding to succeed. By the 
> definitions I'm using here, that is exactly a data plane change.
>
> What, precisely, is then being claimed?
>
> Thanks,
>
> -John
> ___
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$
___
spring mailing list
spring@ietf.org

Re: [spring] CSID proposed clarifications

[Ron Bonica]

Authors,

Could you update the draft to reflect the new pseudocode, below. It is 
essential to the 6man review.


  Ron




Juniper Business Use Only
From: spring  On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, October 14, 2021 8:54 AM
To: SPRING WG 
Subject: [spring] CSID proposed clarifications

[External Email. Be cautious of content]

The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar.
In both cases the SID in the IPv6 Destination Address (DA) contains an argument,
that argument is used to construct the next SID from the active segment in
the SRH Segment List.

I believe the following pseudocode is a much better description of their
segment endpoint processing. You'll notice there is no manipulation of
the bits in the IPv6 DA.

I propose we replace the pseudocode in the draft with the following,
stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors
of the END behavior (sections 4.1.1 and 4.2.1 respectively).

Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID
flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and
NEXT-AND-REPLACE-C-SID flavor.

Comments are appreciated.

Thanks
  Darren

4.1.1.  End with NEXT-C-SID

When processing an IPv6 packet that matches a FIB entry locally
instantiated as an End SID with the NEXT-C-SID flavor, the SRH
processing described in Section 4.1 of [RFC8986] is replaced as
follows.


S.01 When an SRH is processed {
S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
S.03 Stop processing the SRH, and proceed to process the next
 header in the packet, whose type is identified by
 the Next Header field in the routing header.
S.04  }

S.05  If (IPv6.HopLimit <= 1) {
S.06 Send an ICMP Time Exceeded message to the Source Address
 with Code 0 (Hop limit exceeded in transit),
 interrupt packet processing, and discard the packet.
S.07  }

S.08  # Determine the maximum SRH Last Entry
S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

S.10  Initialize 128-bit buffer memory S to 0.
S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument

S.12  If (Argument == 0) {
S.13If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.14  Send an ICMP Parameter Problem to the Source Address
   with Code 0 (Erroneous header field encountered)
   and Pointer set to the Segments Left field,
   interrupt packet processing, and discard the packet.
S.15}

S.16Decrement SRH.SegmentsLeft by 1

S.17Set S to the value of SRH.SegmentList[SRH.SegmentsLeft]
S.18  }
S.19  Else {
S.20If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.21  Send an ICMP Parameter Problem to the Source Address
  with Code 0 (Erroneous header field encountered)
   and Pointer set to the Segments Left field,
   interrupt packet processing, and discard the packet.
S.22}

S.23Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator 
block)

S.24If (SRH.SegmentsLeft > SRH.LastEntry) {
S.25  Initialize local parameter ActiveSegment to the value of DA
S.26}
S.27Else {
S.28  Initialize local parameter ActiveSegment to the value
S.29   of SRH.SegmentList[SRH.SegmentsLeft]
S.30}

S.31Initialize local parameter BitLength to 
(CountTrailingZeros(ActiveSegment) +
  AL - 
CountTrailingZeros(Argument))
S.32Initialize local parameter BitIndex to (128 - BitLength)

S.33Set S[B..B+BitLength-1] to the value of
 ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
S.34  }

S.35  Set IPv6.DA to the value of S

S.36  Decrement IPv6.HopLimit by 1

S.37  Submit the packet to the egress IPv6 FIB lookup for transmission
   to the new destination.
S.38 }

4.1.1.1 Upper layer header processing

The upper-layer header processing described in Section 4.1.1 of
[RFC8986] is replaced as follows.

S.01  Initialize local parameter Argument to the value of IPv6.DA.Argument
S.02  If (Argument != 0) {
# In this case, the SRH was not added by source
# The source compressed it into the active segment in IPv6.DA
# Build a pseudo header from the active segment in the IPv6.DA for use
  # during processing.
S.03Initialize a 24-byte local SRH in memory to 0's for use below
S.04Set SRH.MaxHdrLen to 3
S.05Set SRH.RoutingType to 4
S.06Set SRH.SegmentsLeft to 0
S.07Set SRH.SegmentList[0] to the value of IPv6.DA

S.08Process the SRH as per section 4.1.1,
S.09 noting such processing is limited to the pseudo SRH
S.10 since Argument is not 0.
S.11  }

S.12  If (Upper-Layer header type is allowed by local configuration) {
S.13Proceed to process the Upper-Layer header
S.14  } Else {
S.15Send an ICMP Parameter Problem to the Source Address
 with Code 

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Jim,

Before accepting this document, we might want to discuss why the NEXT-C-SID 
behavior and the REPLACE-C-SID behavior are both needed. Even if there are use 
cases in which one performs slightly better than the other, it the performance 
improvement really worth all of the additional complexity?


 Ron




Juniper Business Use Only
From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Tom,

There is a difference between C-SID and the common mobile practice..

Consider an SRv6 domain where:

- The common prefix is 2001:db8::/48
- Each C-SID is 16 bits long
- Node A instantiates the segment 2001:db8:1::/128

The following are all addresses of Node A:

- 2001:db8:2:1::/128
- 2001:db8:3:1::/128
-2001:db8:2:3:1::/128
- And billions of others...

Yes, they are all drawn from 2001:db8::/48. But Node A is not the sole owner of 
2001:db8::/48.

   Ron



Juniper Business Use Only

-Original Message-
From: Tom Herbert  
Sent: Monday, October 11, 2021 8:48 PM
To: Ron Bonica 
Cc: Brian E Carpenter ; Robert Raszuk 
; 6MAN <6...@ietf.org>; SPRING WG 
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]


On Mon, Oct 11, 2021 at 4:14 PM Ron Bonica 
 wrote:
>
> Folks,
>
> It is much more simple than this.
>
> According to RFC 8200, an IPv6 Destination Address is the “128-bit address of 
> the intended recipient of the packet (possibly not the ultimate recipient, if 
> a Routing header is present). See [RFC4291] and Section 4.4.”
>
> Therefore, if a packet does not contain a Routing header, its IPv6 
> Destination Address is the 128-bit address of its *ultimate recipient*.
>
> Therefore, a node MUST have billions of IPv6 addresses in order to consume a 
> packet:
>
> - that does not have a Routing header
> - whose IPv6 destination address is a 128-bit carrier C-SID
>
> This is because billions of carrier CSIDs can be used to route the packet to 
> that node.
>
> The vast majority of those addresses are not configured on the node.
>
> I am pretty sure that this is not what RFC 8200 had in mind.

Ron,

I'm not sure I understand this. Isn't it already common practice in mobile 
networks to assign each host its own /64 from which the host can use SLAAC to 
dynamically create fully qualified and routable 128-bit addresses? If such a 
host wants to create one, two, or a billion addresses from that space for its 
own purposes then what does the Internet or the protocol care? In fact, the 
idea of creating a unique source address for each client TCP connection has 
already been floated as there are potential advantages for privacy by 
obfuscating addresses to prevent third parties from making correlations to 
identify the sender of different flows (e.g.
draft-herbert-ipv6-prefix-address-privacy).

Tom

>
> Ron
>
>
>
>
>
> Billions of unique 128-bit CSID containers can steer a packet to a particular 
> node. Therefore, that node must have billions of addresses, the vast majority 
> of which are not configured on the node!!
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: ipv6  On Behalf Of Brian E Carpenter
> Sent: Saturday, October 9, 2021 4:02 PM
> To: Robert Raszuk ; 6MAN <6...@ietf.org>
> Cc: SPRING WG 
> Subject: Re: [spring] 
> draft-filsfilscheng-spring-srv6-srh-compression-02
>
> [External Email. Be cautious of content]
>
>
> On 10-Oct-21 00:39, Robert Raszuk wrote:
> > Hi Brian,
> >
> >> Which means: 64 bits.
> >
> > Sorry but what is so magic about /64 here ?
>
> It is mandated by the current IPv6 addressing architecture. Despite many 
> discussions, there has never been consensus to change it. So if /64 is not 
> the boundary between the routeable part and the host-specific part, it's not 
> IPv6.
>
>Brian
>
> >
> > Is this coming from the longest routable IPv6 prefix ? Sort of analogy to 
> > /24 in the IPv4 world ? Or something else ?
> >
> > I think LPM and CIDR techniques are pretty well established.
> >
> > Any fixed length of the address block with the meaning - do not use those 
> > bits inter or intra domain for anything useful even if your prefix+node can 
> > happily fit in /32 seems just dead wrong to me. And that is irrespective of 
> > any SRv6 discussion.
> >
> > In my books if I get allocated say /48 or /40 from RIR what I do with the 
> > remaining bits is my own business.
> >
> > Best,
> > R.
> >
> >
> >
> > > Sorry, but it is a little bit late – RFC 8986 is already published.
> >
> > "Locators are assigned consistent with IPv6 infrastructure allocation."
> >
> > Which means: 64 bits.
> >
> > I have no time to study compressed SIDs, but if they trample on 
> > the
> LOC they are not IPv6 addresses.
> >
> >Brian
> >
> >
> > 
> > IETF

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Folks,

It is much more simple than this.

According to RFC 8200, an IPv6 Destination Address is the “128-bit address of 
the intended recipient of the packet (possibly not the ultimate recipient, if a 
Routing header is present). See [RFC4291] and Section 4.4.”

Therefore, if a packet does not contain a Routing header, its IPv6 Destination 
Address is the 128-bit address of its *ultimate recipient*.

Therefore, a node MUST have billions of IPv6 addresses in order to consume a 
packet:

- that does not have a Routing header
- whose IPv6 destination address is a 128-bit carrier C-SID

This is because billions of carrier CSIDs can be used to route the packet to 
that node.

The vast majority of those addresses are not configured on the node.

I am pretty sure that this is not what RFC 8200 had in mind.

Ron





Billions of unique 128-bit CSID containers can steer a packet to a particular 
node. Therefore, that node must have billions of addresses, the vast majority 
of which are not configured on the node!!

   


Juniper Business Use Only

-Original Message-
From: ipv6  On Behalf Of Brian E Carpenter
Sent: Saturday, October 9, 2021 4:02 PM
To: Robert Raszuk ; 6MAN <6...@ietf.org>
Cc: SPRING WG 
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]


On 10-Oct-21 00:39, Robert Raszuk wrote:
> Hi Brian,
>
>> Which means: 64 bits.
>
> Sorry but what is so magic about /64 here ?

It is mandated by the current IPv6 addressing architecture. Despite many 
discussions, there has never been consensus to change it. So if /64 is not the 
boundary between the routeable part and the host-specific part, it's not IPv6.

   Brian

>
> Is this coming from the longest routable IPv6 prefix ? Sort of analogy to /24 
> in the IPv4 world ? Or something else ?
>
> I think LPM and CIDR techniques are pretty well established.
>
> Any fixed length of the address block with the meaning - do not use those 
> bits inter or intra domain for anything useful even if your prefix+node can 
> happily fit in /32 seems just dead wrong to me. And that is irrespective of 
> any SRv6 discussion.
>
> In my books if I get allocated say /48 or /40 from RIR what I do with the 
> remaining bits is my own business.
>
> Best,
> R.
>
>
>
> > Sorry, but it is a little bit late – RFC 8986 is already published.
>
> "Locators are assigned consistent with IPv6 infrastructure allocation."
>
> Which means: 64 bits.
>
> I have no time to study compressed SIDs, but if they trample on the
LOC they are not IPv6 addresses.
>
>Brian
>
>
> 
> IETF IPv6 working group mailing list
> i...@ietf.org 
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$

> 
>


IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Inline [RB]

   Ron



Juniper Business Use Only
From: Eduard Metz 
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica 
Cc: 6...@ietf.org; SPRING WG 
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]


Can the SID be viewed as the address of the "interface" to, in this case, the 
function that resides in a node? From a routing / forwarding point of view the 
group of functions is more similar to a network (represented by a prefix, 
rather than a single address), but still.

[RB] In RFC 8986, a classic SRv6 SID represents a *single* function that 
resides on a *single* node. If you like, you can even say that represents a 
*single* interface to a *single* function that resides on a *single* node.

By contrast, a Compressed SID Container (i.e., the 128-bit entity that is 
copied into the IPv6 Destination Address field) represents an entire SR Path. 
Specifically, it represents *many* functions that reside on *many* nodes


For my understanding, apart from that the (definition of) SID may not be 
aligned with the literal text in below RFCs, what is the real problem? Are 
there any protocols that specifically rely on this definition of an IPv6 
address?

[RB] We don't know if there are any protocols that rely on this definition of 
the IPv6 address. And if we don't update RFC 4291 before violating it, we don't 
know if anybody might write such an application in the future.


   Ron


cheers,
  Eduard


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Ahmed,

That is a far cry from recommending anything.


  *   If you take a look at the first page of that slide deck, the DT was 
tasked with enumeration and analysis of requirements. The word "recommend" does 
not appear on that page.
  *   If you look at the third page of that slide deck, you will see that one 
very important requirement (PS/BCP Compliance) was left for the relevant WGs to 
determine.
  *   If you look under the chart, you will see a note that says "All 
requirements are not equally important. The working group must decide which are 
more significant." The WG needs to determine whether the requirements that 
register a difference are significant.

   Ron




Juniper Business Use Only
From: Ahmed Bashandy 
Sent: Wednesday, October 6, 2021 1:21 PM
To: Ron Bonica ; James Guichard 
; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]


If we take a look at the summary table in slide 17 in  the DT presentation at 
last IETF

https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00__;!!NEt6yMaO-gk!XRu-vlE4UU8DQXBtTSicMvItj5PBLG69P1RlwJSbtBR6lOLQtnSPeds1ommxXiJY$>

we can see that CSID is the only column with *all blocks dark green*.



Thanks

Ahmed




On 10/6/21 9:06 AM, Ron Bonica wrote:
Ahmed,

I don't recall the DT recommending the CSID. In fact, the word "recommend" does 
not appear anywhere in the analysis document.

As a member of the DT, I don't recommend CSID.

   Ron



Juniper Business Use Only
From: spring <mailto:spring-boun...@ietf.org> On 
Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard 
<mailto:james.n.guich...@futurewei.com>; SPRING 
WG <mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XRu-vlE4UU8DQXBtTSicMvItj5PBLG69P1RlwJSbtBR6lOLQtnSPeds1ovJ2hhnQ$>

[External Email. Be cautious of content]


I support the adoption of this document.

  1.  The network programming model (RFC8986) defines multiple behaviors, CSID 
is just adding the next and replace flavors
  2.  The draft proposes a single SRv6 based data plane that defines next and 
replace behaviors. IMO that is consistent with RFC8986

  1.  CSID has been recommended by the design team for SRv6 based compression
  2.  Interop was done. That is more evidence that CSID is a single data plane 
solution
  3.  IMO CSID is ready to become the basis for the SRv6 compression solution
  4.  Being an SRv6 data plane-based solution, CSID is coherent with the one 
data plane solution objective
  5.  CSID meets SRv6 compression requirements as single solution



Thanks



Ahmed


On 10/1/21 7:04 AM, James Guichard wrote:
Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$>
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$>
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication.

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Folks,

We appear to dancing around the meaning of the words "solution", "behavior", 
and "flavor".  While this dance is semantically elegant, it is neither 
productive nor uplifting.

A better way to determine whether NEXT-C-SID and REPLACE-C-SID are both needed 
is with a tiny bit more analysis. Specifically:


  *   Determine whether NEXT-C-SID and a REPLACE-C-SID yield the same 
compression efficiency. That is, update Table 12 through 15 in the analysis 
document, replacing the CSID column with a CSID NEXT-C-SID and a CSID 
REPLACE-C-SID column.
  *   Determine whether NEXT-C-SID and a REPLACE-C-SID are compatible with one 
another. That is, provide an example where an SR path contains 8 segments. Odd 
numbered segments use NEXT-C-SID and even numbered segments use REPLACE-C-SID. 
What does the packet look like when it arrives at the first segment. How does 
it change at each subsequent segments. (Yes, I know that you recommend against 
doing this for "operational simplicity". But we aren't trying to determine if 
it is simple. We are trying to determine if NEXT-C-SID and a REPLACE-C-SID work 
well together at all.)
  *   Determine whether both are needed. That is, describe a use case where one 
works well and another does not.

I think that this will be much more productive than arguing about "flavors". 
That is, unless the flavor is "pumpkin spice".


 Ron




Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk ; Ron Bonica 
Cc: James Guichard ; SPRING WG 
; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Adding to this Robert, indeed SRv6 defines many behaviors.  The question asked 
about a single 'behavior' could really only be interpreted as asking about 
single 'solution', as you understood, since a single 'behavior' in SRv6 is 
non-sensical.  The requirements draft section 4.2 alone requires multiple 
behaviors be supported, and multiple compression levels in 4.4.4.

Darren

On 2021-10-05, 4:24 PM, "spring" 
mailto:spring-boun...@ietf.org>> wrote:

Ron & SPRING WG chairs,

Through this discussion we first have seen a debate if we need one or more data 
planes to compress SIDs in SRv6. WG clearly stated we need one.

Following that we have observed a first terminology shift to see if asking how 
many solutions should be supported will work any better. To that many WG 
members clearly stated that they support one solution.

Well please notice that the draft in question in its introduction states:

Abstract

   This document defines a compressed SRv6 Segment List Encoding in the
   Segment Routing Header (SRH).  This solution does not require any SRH
   data plane change nor any SRv6 control plane change.  This solution
   leverages the SRv6 Network Programming model.

So based on my understanding of English the entire draft talks about a single 
solution.

Then suddenly a new question popped up: how many behaviours are acceptable.

I bet number of folks including myself said "one" keeping in mind previous 
discussions and the definition of "one" meaning based on the SRv6 data plane in 
compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours but flavors 
as new variants of the already defined behaviors in Standards Track RFCs. 
Namely it defines:

4.1.  NEXT-C-SID Flavor
4.2.  REPLACE-C-SID Flavor

The newly defined behaviour End.XPS is optional.

So if there is anything to ask here is to check if WG is ok with two flavors or 
not. I do not recall that question has ever been asked formally during the WG 
adoption call.

With that let's note that optimal compressed SID size may be different network 
to network. One size does not fit all. Draft says:

6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.
   A C-SID length of 32-bit is recommended.

While I personally think 8-bit should be an option, if we choose a single 
flavor we will introduce suboptimality for no good reason. Hardware capable of 
supporting any flavor clearly can do LPM on locator. Also hardware capable of 
supporting one flavor can support few other flavors as this is pretty much just 
an offset game.

Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Pablo,

Ae you sure? Please look at the question as Joel asked it ( 
https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/<https://urldefense.com/v3/__https

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Ahmed,

I don't recall the DT recommending the CSID. In fact, the word "recommend" does 
not appear anywhere in the analysis document.

As a member of the DT, I don't recommend CSID.

   Ron



Juniper Business Use Only
From: spring  On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard ; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]


I support the adoption of this document.

  *   The network programming model (RFC8986) defines multiple behaviors, CSID 
is just adding the next and replace flavors
  *   The draft proposes a single SRv6 based data plane that defines next and 
replace behaviors. IMO that is consistent with RFC8986

  *   CSID has been recommended by the design team for SRv6 based compression
  *   Interop was done. That is more evidence that CSID is a single data plane 
solution
  *   IMO CSID is ready to become the basis for the SRv6 compression solution
  *   Being an SRv6 data plane-based solution, CSID is coherent with the one 
data plane solution objective
  *   CSID meets SRv6 compression requirements as single solution



Thanks



Ahmed


On 10/1/21 7:04 AM, James Guichard wrote:
Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel




___

spring mailing list

spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Pablo,

Ae you sure? Please look at the question as Joel asked it ( 
https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ).


 Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, October 5, 2021 2:58 PM
To: Ron Bonica ; James Guichard 
; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: RE: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Ron,

I believe your statement is wrong. The WG has expressed strong preference for a 
single data plane solution.

From the chairs emails:
“Given that the working group has said that it wants to standardize one data 
plane solution …”
“There is a rough (quite clear) consensus for standardizing one dataplane 
solution…”

I hope we all agree that RFC8986 is not defining 36 different dataplane 
solutions. 

Cheers,
Pablo.

From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: martes, 5 de octubre de 2021 17:38
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>; 
James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: RE: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Pablo,

The WG has expressed a strong preference for having a single compression 
*behavior*. Why is it OK to ignore that preference because RFC 8986 has 36 
different behaviors?

Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Pablo Camarillo (pcamaril)
Sent: Monday, October 4, 2021 1:32 PM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XFki7y49hq-_1n9wivZdbA_IuaMQ3UTYwF-IRESDd-5OL-dV-ZwAUUkScxGGLS_d$>


RFC8986 already defines 36 different behaviors.

This document, CSID, is a single SRv6-based solution that only defines 
additional behaviors with the next and replace flavors.



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/

[Ron Bonica]

Jim,

The call for adoption has already been posted. There is no way to put that 
toothpaste back into its tube. However, I strongly recommend against such calls 
for adoption in the future.

Normally, the authors of a document are encouraged to answer technical 
questions as a condition of adoption. Bullet points 1, 2, and 4 in the call for 
adoption defer that requirement until WG last call. Could this be why technical 
questions are not being addressed during the call for adoption.

In some extreme conditions, it may be necessary to modify the usual call for 
adoption procedure. But these exceptional conditions have not been articulated.

It is unfortunate that two of the three working group chairs are also 
co-authors of the draft. While there may not have been any impropriety, the 
appearance of impropriety is difficult to avoid.


   Ron




Juniper Business Use Only
From: spring  On Behalf Of James Guichard
Sent: Monday, October 4, 2021 11:10 AM
To: ext-andrew.als...@liquidtelecom.com ; 
SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Andrew,

As stated in our email of September 9th, the chairs communicated that the 
working group reached rough (quite clear) consensus for standardizing one data 
plane solution to compress segment routing over IPv6. In addition to this there 
was an inclination toward using the CSID document as the basis for our work in 
this area. The chairs recognized that there was however disagreement as to 
whether this document, having multiple SRv6 EndPoint behaviors, could be 
considered consistent with the working group consensus for a single data plane 
solution. This issue quite clearly needed to be addressed, and the chairs, 
recognizing that the working group is keen to make progress in this area, had 
the option of trying to resolve the issue prior to issuing an adoption call, or 
give the working group the opportunity to express their opinions as part of a 
call for adoption.

Those who feel that we need to resolve the consistency issue before adoption, 
as with those who think this is not a good basis for the WG work, are free and 
expected to object to the WG adopting the document. That is distinct from 
objecting to the chairs issuing the adoption call.

In essence, the chairs have combined the question of when to resolve 
consistency and the question of whether this document is a good basis for the 
WG into one call.

Yours,

Jim, Bruno & Joel


From: Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org
Subject: Re: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry - but - I'm a little confused here.

Because the way I look at this - the working group clearly stated that they 
wished for a single behavior - and this - does not deliver that - it is two 
separate behaviors.  As such - I see this call for adoption - irrespective of 
the merits or lack thereof of the draft, as a clear defiance of the stated will 
of the working group.

This is simply does not fit into the definition of bottom up approach in my 
opinion - and if this is the way that the chairs wish to proceed - then the 
only way to do that and still fit within the bottom up approach is to first ask 
this working group for its consensus to deviate from the single behacvior 
approach that the working group agreed to.

As such - I must  strongly and unequivocally object to this call for adoption

Andrew

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
mailto:james.n.guich...@futurewei.com>>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org 
mailto:spring-cha...@ietf.org>>
Subject: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Folks,

In a private communication, someone asked for specific references to RFCs 8200 
and 4291 that were difficult to harmonize with 
draft-filsfilscheng-spring-srv6-srh-compression. References follow:

Section 3 of RFC 8200
-
"The Destination Address field of the IPv6 header contains the "128-bit address 
of the intended recipient of the packet (possibly not the ultimate recipient, 
if a Routing header is present).  See [RFC4291] and Section 4.4."

Section 2 of RFC 4291
-
"IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces 
(where "interface" is as defined in Section 2 of [RFC8200])".

Section 2 of RFC 8200
--

  *   An interface is "a node's attachment to a link"
  *   A link is "a communication facility or medium over which nodes can 
communicate at the link layer, i.e., the layer immediately below IPv6."

So, an IPv6 Destination Address represents a single thing that is instantiated 
on a single node.

According to draft-filsfilscheng-spring-srv6-srh-compression-02, A 
Compressed-SID container (C-SID container) is "an entry of the SRH Segment-List 
field (128 bits) that contains a sequence of C-SIDs." A C-SID is "a  C-SID is a 
short encoding of a SID in SRv6 packet that does not include the SID block bits 
(locator block)."

According to RFC  8896, a SID identifies an instruction on a node.

And finally, according to draft-filsfilscheng-spring-srv6-srh-compression-02, 
an SRv6 node can copy a container C-SID to the  Destination Address fieldd of 
theIPv6 header.

When this happens, the IPv6 Destination Address doesn't represent a single 
thing on a single node. It represents an entire SR path.

        
Ron




Juniper Business Use Only
From: Ron Bonica
Sent: Friday, October 1, 2021 4:35 PM
To: 6...@ietf.org
Cc: SPRING WG 
Subject: draft-filsfilscheng-spring-srv6-srh-compression-02

Folks,

Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID 
types that can occupy the Destination Address field of an IPv6 header. See 
Sections 4.1, 4.2, and 4.3 of the draft for details.

The SPRING WG has issued a call for adoption for this draft.

It is not clear that these SID types can be harmonized with the IPv6 addressing 
architecture.

Does anyone have an opinion?


   Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Pablo,

The WG has expressed a strong preference for having a single compression 
*behavior*. Why is it OK to ignore that preference because RFC 8986 has 36 
different behaviors?

Ron




Juniper Business Use Only
From: spring  On Behalf Of Pablo Camarillo (pcamaril)
Sent: Monday, October 4, 2021 1:32 PM
To: James Guichard ; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/


RFC8986 already defines 36 different behaviors.

This document, CSID, is a single SRv6-based solution that only defines 
additional behaviors with the next and replace flavors.



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Brian,

Is there any limit to the degree that one Internet Standard can violate 
another, so long as that violation is constrained to a limited domain?

For example, if I wanted to reduce the size of IPv6 header by shrinking the 
source and destination addresses to 64 bits each, would that be OK?


 Ron



Juniper Business Use Only

-Original Message-
From: Brian E Carpenter  
Sent: Monday, October 4, 2021 4:05 PM
To: Tony Przygienda 
Cc: Ron Bonica ; 6...@ietf.org; SPRING WG 
Subject: Re: draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]


Tony,
On 05-Oct-21 02:32, Tony Przygienda wrote:
> Taking this new "philosophy of limited domain" to its bitter 
> conclusion
>
> A is Internet Standard
> B is also Internet Standard for "Limited Domain" that violates A C is 
> also Internet Standard for "Limited Domain" that violates A D is also 
> Internet Standard for "Limited Domain" that violetes C
>
> so by transitive chain D violates C and hence A but not B. Hence D and B can 
> be deployed together (maybe) but not any other combination.
>
> So what purposes will IETF serve. To define 4 different "standards" that have 
> "limited domain violation dependencies" amongst each other but based on 
> algebra closure can sometimes be deployed together. And we will track this 
> and call that "standards" ? Really ?

There's an attempted analysis of this issue at 
https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8799.html*name-the-scope-of-protocols-in-l__;Iw!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG7y06gGZe$
  (which is not, of course, an IETF document).

   Brian

>
> --- tony
>
>
>
>
>
> On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter  <mailto:brian.e.carpen...@gmail.com>> wrote:
>
> Ron,
>
> The first sentence cites RFC8402 which unambiguously describes SR as a
> limited domain protcol (limited to an "SR domain", that is.)
>
> So within such a domain, this describes using 128 bit quantities called
> Segment Identifiers that in some cases, but apparently not in the formats
> defined here, has the same structure as an IP address.
>
> Does that harm the Internet, even if it leaks? It might disappoint the
> sender, as any sender of a bogus packet is disappointed, but apart from 
> that,
> who is damaged?
>
> Regards
>Brian Carpenter
>
> On 02-Oct-21 09:34, Ron Bonica wrote:
> > Folks,
> >
> >
> >
> > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new
> SID types that can occupy the Destination Address field of an IPv6 
> header. See Sections 4.1, 4.2, and 4.3 of the draft for details.
> >
> >
> >
> > The SPRING WG has issued a call for adoption for this draft.
> >
> >
> >
> > It is not clear that these SID types can be harmonized with the IPv6 
> addressing architecture.
> >
> >
> >
> > Does anyone have an opinion?
> >
> >
> >
> > 
>Ron
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> >
> > 
> > IETF IPv6 working group mailing list
> > i...@ietf.org <mailto:i...@ietf.org>
> > Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$
>   
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$
>  >
> > 
> >
>
> 
> IETF IPv6 working group mailing list
> i...@ietf.org <mailto:i...@ietf.org>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3f
> aGG74XUosUG$
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$
 >
> 
> 
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [srcomp] compression analysis draft question on proposals analyzed

[Ron Bonica]

And more specifically, all of the tables in Section A.2 will be modified, 
replacing the C-SID column with one column for NEXT-C-SID, one column for 
REPLACE-C-SID, and one column for NEXT-AND-REPLACE-C-SID

   Ron




Juniper Business Use Only
From: spring  On Behalf Of Gyan Mishra
Sent: Saturday, October 2, 2021 7:51 AM
To: Darren Dukes (ddukes) 
Cc: src...@ietf.org; SPRING WG 
Subject: Re: [spring] [srcomp] compression analysis draft question on proposals 
analyzed

[External Email. Be cautious of content]


Thanks Darren!

On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Was: Re: [spring] 
draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1

I'm sending this note to redirect this question to the srcomp DT for an 
editorial fix, when the team meets next.

For the DT:
Each proposal, introduced in section 1, discusses how it supports 16-bit and 
32-bit SIDs. However, Gyan's question indicates this could be more clearly 
stated in the analysis draft to help readers less familiar with a proposal.  As 
such, section 1 can be improved accordingly.

Darren

On 2021-09-24, 1:32 PM, "spring" 
mailto:spring-boun...@ietf.org>> wrote:

Gyan,

You raise a very good point. In the analysis document, Tables 1 through 6 and 
Tables 12 through 15 each contain only one column for the CSID. They do not 
indicate whether the number in that column were calculated using the 
NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not 
indicate whether they were calculated using uSID, G-SID, or a combination of 
both).

Each of these tables should be modified, so that the CSID column is replaced by 
three columns (NEXT-C-SID, REPLACE-C-SID, and NEXT-AND-REPLACE-C-SID).

If the numbers in these columns are different from one another, this may inform 
our discussion about whether NEXT-C-SID, REPLACE-C-SID, and 
NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a 
behavior.

   
Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG mailto:spring@ietf.org>>; 
draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org;
 spring-cha...@ietf.org
Subject: Re: [spring] 
draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1

[External Email. Be cautious of content]

Dear Spring Authors

Please respond to this question the WG has related to which of the three SRv6 
forwarding mechanisms called  flavors was inclusive of the compression analysis 
draft.

The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor was 
part of the analysis.

This is a critical question that has come up by the WG and Chairs, and 
answering this question will help pave the way to an adoption call for C-SID.

Kind Regards

Gyan

On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Dear Authors

After having a few discussions on threads related to the SRv6 compression 
analysis draft results, as well as WG coming to consensus on a single SRv6 
compression solution, a few critical questions have come up related to C-SID 
draft that requires clarification by the authors.

The C-SID draft has 3 compression solutions below and is a combination of the 
two drafts below which introduces 2 of the 3 compression solutions with the  
C-SID draft introduction of yet a 3rd compression solution.

Which of the 3 C-SID draft compression solutions was included as part of the DT 
analysis draft results and conclusion?

This is a critical question that needs to be answered for clarification on the 
C-SID draft solution.

As the WG has consensus on a single solution we need to have clarification from 
the authors which of the 3 compression solutions was included in the analysis.

The three solutions are very different and all would yield different analysis 
results.

I understand the authors have called the each solution a endpoint flavor which 
I see from the IANA codepoint allocations, however each flavor is a different 
solution.

https://www.iana.org/assignments/segment-routing/segment-routing.xhtml

So the WG as stated would like a single solution so now we need feedback from 
the authors which of the three solutions or endpoint flavors was part of the DT 
analysis draft that the authors would like to put forward as the single 
compression solution.

C-SID is a combination of the two drafts below:

Combination of the two drafts below:

G-SID - Generalized SID "REPLACE-C-SID"

Re: [spring] CSID Question

[Ron Bonica]

Aihua,

I don’t recall this being discussed in the design team, but my memory may be 
failing me. The design team kept meticulous minutes ( 
https://mailarchive.ietf.org/arch/browse/srcomp/ ) and it would be very helpful 
of you could point me the meeting where this was discussed.

I agree that it would be difficult to find a use-case where both G-SID and uSID 
are both required. However, I ask the question for the following reasons:


  *   To determine whether G-SID and uSID are different behaviors. If they 
don’t work well together in a single domain, it would be difficult to argue 
that they are a single behavior
  *   To determine whether they are both needed.
  *   To determine whether the C-SID encapsulation overhead reduction 
statistics reported in the analysis document reflect uSID only, G-SID only, or 
a combination of both


 Ron




Juniper Business Use Only
From: liu.ai...@zte.com.cn 
Sent: Saturday, October 2, 2021 9:03 PM
To: Ron Bonica 
Cc: rob...@raszuk.net; spring@ietf.org
Subject: Re:[spring] CSID Question

[External Email. Be cautious of content]




Hi Ron,

You raised an interesting question, but I think it might be already discussed 
in the DT. In my understanding, this question is just more related the usecases 
and requirements but the solutions. In a SRv6 domain, the header compression 
effection depends on the SID informaion redundencies due to the reasonable SID 
planning with the SRv6 compatible solution. I think it's meanless to compress 
the SRv6 header in the case of random SID format. Besides other solution 
without engouth SRv6 compatible such as Unified SID could be used to resolve 
the usecase you mentioned. I believe that had been discussed and compared 
within the DT and the one solution compatible with SRv6 is preferred, that is 
the CSID draft.



Best Regards,

Aihua


原始邮件
发件人：RonBonica
收件人：Robert Raszuk;
抄送人：SPRING WG;
日 期 ：2021年10月02日 21:39
主 题 ：Re: [spring] CSID Question
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring

Folks,
Now that Robert and I have provided some entertainment, could someone answer 
the technical question that initiated this thread?

Does the document recommend against using Next-C-SId and Replace-C-Sid in the 
same domain  for ease of operation or because they don’t work well together? If 
the former, please provide the example described below.

  Ron


Sent from my iPhone

On Oct 1, 2021, at 5:07 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:



[External Email. Be cautious of content]



Hi Ron,


  *   Can we say that they are a single behavior ?

No. And neither RFC8986 defines a single behavior or single flavor. Yet the 
bounds are clearly set what is the SRv6 data plane.

For some strange reason I am observing here an attempt to squeeze different 
data plane into the room which is not compliant to [RFC8402], [RFC8754] and 
[RFC8986]. Do you think anyone will be so naive to accept it ?

Now I am going to rest assured and enjoy the rest of this show.

Best,
Robert


On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Robert,

I do remember that quote. And that is exactly why I ask the question!

If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:


  *   Can we say that they are a single behavior ?
  *   Can we justify both because each is optimized for a different kind of 
network?
  *   Can we justify another behavior either because it is optimized for yet 
another type of network or because it does relatively well in all network types?

However, if this is just an “ease of operation” thing, as stated in the draft, 
the authors are obliged to answer my question.


 Ron

P.S. Rest assured that I have read the draft. However, your concern is greatly 
appreciated 




Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [spring] CSID Question

[External Email. Be cautious of content]

Hi Ron,

Have you read this draft ?

Quote from it:


   It is recommended for ease of operation that a single compressed

   encoding flavor be used in a given SRv6 domain.  However, in a multi-

   domain deployment, different flavors can be used in different

   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
CSID Authors,

Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7 
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END 
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.

Please provide an example that

Re: [spring] CSID Question

[Ron Bonica]

Folks,

Now that Robert and I have provided some entertainment, could someone answer 
the technical question that initiated this thread?

Does the document recommend against using Next-C-SId and Replace-C-Sid in the 
same domain  for ease of operation or because they don’t work well together? If 
the former, please provide the example described below.

  Ron



Sent from my iPhone

On Oct 1, 2021, at 5:07 PM, Robert Raszuk  wrote:



[External Email. Be cautious of content]


Hi Ron,


  *   Can we say that they are a single behavior ?

No. And neither RFC8986 defines a single behavior or single flavor. Yet the 
bounds are clearly set what is the SRv6 data plane.

For some strange reason I am observing here an attempt to squeeze different 
data plane into the room which is not compliant to [RFC8402], [RFC8754] and 
[RFC8986]. Do you think anyone will be so naive to accept it ?

Now I am going to rest assured and enjoy the rest of this show.

Best,
Robert


On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Robert,

I do remember that quote. And that is exactly why I ask the question!

If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:


  *   Can we say that they are a single behavior ?
  *   Can we justify both because each is optimized for a different kind of 
network?
  *   Can we justify another behavior either because it is optimized for yet 
another type of network or because it does relatively well in all network types?

However, if this is just an “ease of operation” thing, as stated in the draft, 
the authors are obliged to answer my question.


 Ron

P.S. Rest assured that I have read the draft. However, your concern is greatly 
appreciated 




Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [spring] CSID Question

[External Email. Be cautious of content]

Hi Ron,

Have you read this draft ?

Quote from it:


   It is recommended for ease of operation that a single compressed

   encoding flavor be used in a given SRv6 domain.  However, in a multi-

   domain deployment, different flavors can be used in different

   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
CSID Authors,

Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7 
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END 
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.

Please provide an example that shows us:


  *   What the SRH looks like as it arrives at the first segment endpoint
  *   What the IPv6 Destination Address looks like at each segment endpoint, 
including information required to parse the Destination Address


   Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UL_LsTEWuybtewcIHX2FwrqtwS3G97ki3tzHT8pGyGcx2hPWYZfriSmeG75uwP7l$>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CSID Question

[Ron Bonica]

Robert,

I do remember that quote. And that is exactly why I ask the question!

If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain:


  *   Can we say that they are a single behavior ?
  *   Can we justify both because each is optimized for a different kind of 
network?
  *   Can we justify another behavior either because it is optimized for yet 
another type of network or because it does relatively well in all network types?

However, if this is just an “ease of operation” thing, as stated in the draft, 
the authors are obliged to answer my question.


 Ron

P.S. Rest assured that I have read the draft. However, your concern is greatly 
appreciated 




Juniper Business Use Only
From: Robert Raszuk 
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica 
Cc: SPRING WG 
Subject: Re: [spring] CSID Question

[External Email. Be cautious of content]

Hi Ron,

Have you read this draft ?

Quote from it:


   It is recommended for ease of operation that a single compressed

   encoding flavor be used in a given SRv6 domain.  However, in a multi-

   domain deployment, different flavors can be used in different

   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
CSID Authors,

Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7 
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END 
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.

Please provide an example that shows us:


  *   What the SRH looks like as it arrives at the first segment endpoint
  *   What the IPv6 Destination Address looks like at each segment endpoint, 
including information required to parse the Destination Address


   Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UL_LsTEWuybtewcIHX2FwrqtwS3G97ki3tzHT8pGyGcx2hPWYZfriSmeG75uwP7l$>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] draft-filsfilscheng-spring-srv6-srh-compression-02

[Ron Bonica]

Folks,

Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID 
types that can occupy the Destination Address field of an IPv6 header. See 
Sections 4.1, 4.2, and 4.3 of the draft for details.

The SPRING WG has issued a call for adoption for this draft.

It is not clear that these SID types can be harmonized with the IPv6 addressing 
architecture.

Does anyone have an opinion?


   Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] CSID Question

[Ron Bonica]

CSID Authors,

Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and 7 
are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END 
SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.

Please provide an example that shows us:


  *   What the SRH looks like as it arrives at the first segment endpoint
  *   What the IPv6 Destination Address looks like at each segment endpoint, 
including information required to parse the Destination Address


   Ron



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Ron Bonica]

Chairs,

I strongly object to the adoption of this draft.

I also note that this is a very strange adoption call. The WG has indicated a 
preference for a single forwarding plane behavior. However, bullets #1 and #4 
in the Call for Adoption suggest that the WG has yet to address whether the 
draft satisfies its single behavior objective.

If the draft does not satisfy the single behavior objective, two of the three 
behaviors specified in the draft will need to be removed. This is a weak 
starting point for a standards track RFC.

Furthermore, neither this WG nor 6man has determined whether all three 
behaviors are compliant with RFC 4291. It seems to me that one is while the 
other two are not.

Finally, I question the benefit of adopting this draft *before* the above 
mentioned questions are answered. This is not a rhetorical question. A response 
from the chairs would be appreciated.


  Ron




Juniper Business Use Only
From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Thoughts on optimality

[Ron Bonica]

Tony,

Thanks for pointing out that all requirements are not equally important. Some 
may be extremely important while others are minimally important. Therefore, our 
analysis should focus on the important requirements.

I agree that Encapsulation Header Size is the most important requirement. I 
also agree that the Forwarding Efficiency requirement would be important, if it 
were well-formed. However, I am not sure that it is well-formed.

The Forwarding Efficiency requirement assumes that the only significant factors 
in forwarding efficiency are:

- Number of lookups
- Number of headers parsed

Are we sure that:

- there isn't a third significant factor that we are leaving out
- the cost of parsing a header may be high on one ASIC and minimal on another

And as you say, next-generation ASICs will be designed to accommodate whatever 
solution we choose.

   Ron



Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Tony Li
Sent: Thursday, September 16, 2021 6:24 PM
To: spring@ietf.org
Subject: [spring] Thoughts on optimality

[External Email. Be cautious of content]


Hi all,

We now seem headed to be adopting both the requirements and analysis drafts and 
thoughts start to turn towards the debate for selection.

The requirements draft has done a good job documenting our requirements and the 
analysis draft gives us a perspective on how the various proposals fulfill 
those requirements, but a deeper nuance is needed to guide us to making an 
optimal choice.

To that end, it seems to me that three of the requirements are paramount:

- Encapsulation Header Size
- Forwarding Efficiency
- State Efficiency

Of these three, Forwarding Efficiency and State Efficiency seem like they will 
be overcome by hardware technology.  Continued growth in semiconductors will 
help us scale here, so the remaing requirement of the Encapsulation Header Size 
would seem to predominate, and we should therefore optimize for that.

Regards,
Tony

___
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Te0PqyNCrRUDlLu1jwh3rO2ORVQFKRYu1ylhbeMZRmO1yFomVpfU8XS1Ze-x3fi8$

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1

[Ron Bonica]

Gyan,

You raise a very good point. In the analysis document, Tables 1 through 6 and 
Tables 12 through 15 each contain only one column for the CSID. They do not 
indicate whether the number in that column were calculated using the 
NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not 
indicate whether they were calculated using uSID, G-SID, or a combination of 
both).

Each of these tables should be modified, so that the CSID column is replaced by 
three columns (NEXT-C-SID, REPLACE-C-SID, and NEXT-AND-REPLACE-C-SID).

If the numbers in these columns are different from one another, this may inform 
our discussion about whether NEXT-C-SID, REPLACE-C-SID, and 
NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a 
behavior.

   
Ron




Juniper Business Use Only
From: spring  On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG ; 
draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] 
draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1

[External Email. Be cautious of content]

Dear Spring Authors

Please respond to this question the WG has related to which of the three SRv6 
forwarding mechanisms called  flavors was inclusive of the compression analysis 
draft.

The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor was 
part of the analysis.

This is a critical question that has come up by the WG and Chairs, and 
answering this question will help pave the way to an adoption call for C-SID.

Kind Regards

Gyan

On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Dear Authors

After having a few discussions on threads related to the SRv6 compression 
analysis draft results, as well as WG coming to consensus on a single SRv6 
compression solution, a few critical questions have come up related to C-SID 
draft that requires clarification by the authors.

The C-SID draft has 3 compression solutions below and is a combination of the 
two drafts below which introduces 2 of the 3 compression solutions with the  
C-SID draft introduction of yet a 3rd compression solution.

Which of the 3 C-SID draft compression solutions was included as part of the DT 
analysis draft results and conclusion?

This is a critical question that needs to be answered for clarification on the 
C-SID draft solution.

As the WG has consensus on a single solution we need to have clarification from 
the authors which of the 3 compression solutions was included in the analysis.

The three solutions are very different and all would yield different analysis 
results.

I understand the authors have called the each solution a endpoint flavor which 
I see from the IANA codepoint allocations, however each flavor is a different 
solution.

https://www.iana.org/assignments/segment-routing/segment-routing.xhtml

So the WG as stated would like a single solution so now we need feedback from 
the authors which of the three solutions or endpoint flavors was part of the DT 
analysis draft that the authors would like to put forward as the single 
compression solution.

C-SID is a combination of the two drafts below:

Combination of the two drafts below:

G-SID - Generalized SID "REPLACE-C-SID"
https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03

SRv6 uSID micro-segment " NEXT-C-SID"
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10

Kind Regards


Gyan
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Ron Bonica]

Dhruv,

My hope is that the WG will consider each requirement in Appendix A, taking one 
of the following actions for each:


  *   Drop the requirement
  *   Move the requirement into the main body of the text
  *   Modify the requirement and move it into the main body of the text

Each item either is or is not a requirement.

Ron




Juniper Business Use Only
From: spring  On Behalf Of Dhruv Dhody
Sent: Monday, September 20, 2021 12:56 PM
To: bruno.decra...@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]


draft-srcompdt-spring-compression-requirement-07


What is the plan for Appendix A?

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Ron Bonica]

Dhruv,

You raise a very good question. What makes us think that the largest network 
diameter is 16? Next year, it may be 32! Maybe we need to rethink this 
requirement.

An IPv6 routing header can contain no more than 2,048 bytes. Therefore, an SRH 
without compression can support an SR path that contains as many as 127 
segments. Maybe the requirement should be rewritten as follows:

NEW>
   Description: The compression proposal MUST be able to represent SR
   paths that contain up to 127 segments.

   Rationale: The SRH, without compression, can represent SR
   paths that contain up to 127 segments. Compression mechanisms must have the 
same capability.

   Metric: The compression proposal must be able to steer a packet
   through an SR path that contains up to 127 segments.
 On Behalf Of Dhruv Dhody
Sent: Monday, September 20, 2021 12:56 PM
To: bruno.decra...@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[SNIP]


In Section 4.2.3

Description: The compression proposal MUST be able to represent SR paths that 
contain up to 16 segments.
Rationale: Strict TE paths require SID list lengths proportional to the 
diameter of the SR domain.

It would be nice to include why the number "16" in the rationale.

[SNIP]

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Ron Bonica]

Dhruv,

Thanks for you review and support.

Does the change below (inline) address your first comment?

   Ron



Juniper Business Use Only
From: spring  On Behalf Of Dhruv Dhody
Sent: Monday, September 20, 2021 12:56 PM
To: bruno.decra...@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Hi,

I support the adoption of both documents.

Thanks for all the effort put in by everyone involved. Few minor comments -

draft-srcompdt-spring-compression-requirement-07


In section 1

It is a goal of the design team to identify solutions to...
It is also a goal of the design team to consider proposals...
The design team will produce a separate document...

Should we still need to mention the design team in the introduction? If some 
history needs to be maintained, let's put that in the appendix!

[RB]

OLD>

The SPRING working group defined SRv6, with [RFC8402] describing how the 
Segment Routing (SR) architecture is instantiated on two data-planes: SR over 
MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses a routing header called the 
SR Header (SRH) [RFC8754] and defines SRv6

SID behaviors and a registry for identifying them in [RFC8986].  SRv6 is a 
proposed standard and is deployed today.

The SPRING working group has observed that some use cases, such as strict path 
TE, may require long SRv6 SID lists.  There are several proposed methods to 
reduce the resulting SRv6 encapsulation size by compressing the SID list.

The SPRING working group formed a design team to define requirements for, and 
analyze proposals to, compress SRv6 SID lists.

It is a goal of the design team to identify solutions to SRv6 SID list 
compression that are based on the SRv6 standards.  As such, this document 
provides requirements for SRv6 SID list compression solutions that utilize the 
existing SRv6 data plane and control plane.

It is also a goal of the design team to consider proposals that are not based 
on the SRv6 data plane and control plane.  As such, this document includes 
requirements to evaluate whether a compression proposal provides all the 
functionality of SRv6 (section "SRv6 Functionality") in addition to satisfying 
compression specific requirements.

For each requirement, a description, rationale and metrics are described.

The design team will produce a separate document to analyze the proposals.

This document is a draft; additional requirements are under review, additional 
requirements will be added, and current requirements may change.  Appendix A 
contains a subset of requirements without unanimous consensus.  Additional 
requirements without unanimous consensus are not in the appendix.



The Segment Routing (SR) architecture [RFC 8402] can be instantiated on two 
data-planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses a 
routing header called the SR Header (SRH) [RFC8754] and defines SRv6 SID 
behaviors and a registry for identifying them in [RFC8986].  SRv6 is a proposed 
standard and is deployed today.

Some use cases, such as strict path TE, may require long SRv6 SID lists.  There 
are several proposed methods to reduce the resulting SRv6 encapsulation size by 
compressing the SID list.

This document defines requirements for a SID list compression mechanism. For 
each requirement, a description, rationale and metrics are provided.

A companion document [draft-srcompdt-spring-compression-analysis] evaluates 
several compression mechanisms according to compliance with the requirements 
described by this document.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Ron Bonica]

Bruno,

Thanks. This clears up the confusion.

I support adoption.

  Ron






Juniper Business Use Only
From: bruno.decra...@orange.com 
Sent: Monday, September 13, 2021 5:50 AM
To: Ron Bonica 
Cc: spring@ietf.org
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Ron,

It looks to me that you are quite well aware of the whole IETF process; but if 
not [1] may be a good starting pointer.

This WG adoption call is not expected to be any different than other WG 
adoption calls.

You are right that WG adoption of a document means that the WG own the document 
and so its content. But WG adoption of a document only make sense if the wg 
believe that the document is a good starting point: we are not adopting the 
title but the whole document.

Your below email is not crystal clear to me with regards to whether or not you 
have a concern with the document.
If you have specific concern(s) on the document or some part/sentences in the 
document, could you please state those concerns on the mailing list?

>From the informational document that you have cited, below are two questions 
>which seem related to your email. If you wish to, you are also welcome to 
>voice your opinion on these two points.

   *  Does the document provide an acceptable platform for continued effort by 
the working group?

   *  What are the process or technical objections to adoption of the draft?


> If so, I support adoption of this draft.

Which one?


[1] 
https://www.ietf.org/standards/process/<https://urldefense.com/v3/__https:/www.ietf.org/standards/process/__;!!NEt6yMaO-gk!XORaRAzP4eTP5TQKr2ujYE5WK4Cy0_jornjNH4rmA6EVd5o35UD5BZnRhn-sVLRh$>

--Bruno


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, September 10, 2021 9:16 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

Bruno,

When a WG adopts a design team draft, I assume that the draft becomes subject 
to the following guidelines from RFC7221:

"Once a working group adopts a draft, the document is owned by the working 
group and can be changed however the working group decides, within the bounds 
of IETF process and the working group charter.  Absent explicit agreement, 
adopting a document does not automatically mean that the working group has 
agreed to all of its content.  So a working group (or its charter) might 
explicitly dictate the basis for retaining, removing, or modifying some or  
 all of a draft's content, technical details, or the like. However, in the 
absence of such constraints, it is worth having the adoption process include a 
sub-process of gathering working group concerns about the existing draft and 
flagging them explicitly."

Do I have that right?

If so, I support adoption of this draft.

Ron



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Tuesday, September 7, 2021 9:13 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhUozCY2f$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhc0iIRXo$>


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Ron Bonica]

Bruno,

When a WG adopts a design team draft, I assume that the draft becomes subject 
to the following guidelines from RFC7221:

"Once a working group adopts a draft, the document is owned by the working 
group and can be changed however the working group decides, within the bounds 
of IETF process and the working group charter.  Absent explicit agreement, 
adopting a document does not automatically mean that the working group has 
agreed to all of its content.  So a working group (or its charter) might 
explicitly dictate the basis for retaining, removing, or modifying some or  
 all of a draft's content, technical details, or the like. However, in the 
absence of such constraints, it is worth having the adoption process include a 
sub-process of gathering working group concerns about the existing draft and 
flagging them explicitly."

Do I have that right?

If so, I support adoption of this draft.

Ron



Juniper Business Use Only
From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, September 7, 2021 9:13 AM
To: spring@ietf.org
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SRv6 compression

[Ron Bonica]

Tony,

Thanks for these wise words! It is time for the WG to consider the DT output 
and make an informed decision based on best technical reasoning, not current 
popularity, deployment or market share.

IMHO, the requirements and analysis documents are not a ringing endorsement for 
any particular solution. Close examination will reveal that each solution is 
better suited for some use-cases than others, and that each solution has to 
stretch to perform in use-cases where it is not well-suited.

Beyond that, not all requirements are equally important. Some are use-case 
specific. Some may not be interesting at all.

Let us choose carefully!


 Ron



Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Tony Li
Sent: Tuesday, August 3, 2021 10:55 AM
To: Vasilenko Eduard 
Cc: spring@ietf.org; li_zhenqi...@hotmail.com; Andrew Alston 

Subject: Re: [spring] SRv6 compression

[External Email. Be cautious of content]


Hi all,

I have a bit of a different perspective.

Whatever solution is selected, it will be basically forever. Vendors will cut 
this into silicon. Quite literally set in stone. It will get deployed and there 
will be no turning back.
We should pick the best possible solution because we will have to live with it. 
Forever. That far surpasses the pain of having to replace whatever folks have 
deployed so far.

Thus, while I wish no one undue pain, the fact is that current deployment, 
popularity, and market share aren’t compelling reasons to make a selection.
We need the technically optimal solution.

Please choose carefully. Please choose wisely. Please choose for the very long 
haul.

Tony


___
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QI8E3x0zpU-ePOlUDMUg9GDUvHSa12qyO8bjhO9tgJiDnr674jn0qqPseMqRT0BQ$
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SRv6 SID List compression

[Ron Bonica]

Darren,

First, it is important to note that you and I can speak as members of the 
design team, but not on behalf of it. Neither the design team nor the WG chairs 
have commissioned us to do that.

Beyond that, the WG has every right to evaluate whether any candidate solutions 
violate existing BCP or PS documents. You and I have both stated our opinions. 
However, neither you nor I nor a parade of "+1s" can determine the outcome of 
this debate. It is time for technical discussions to begin.

The WG has had access to the requirements document for some time. However:


  *   The requirements has not passed WG LC or even WG adoption. So, its 
contents are not set in stone
  *   The requirements document does not say that all requirements are equally 
important.

Finally, do you disagree with the observation about the composition of the 
design team? If so, what were the actual numbers?


  Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Tuesday, July 27, 2021 6:13 PM
To: SPRING WG 
Cc: Ron Bonica 
Subject: Re: [spring] SRv6 SID List compression

[External Email. Be cautious of content]

Speaking as a design team member, I have some corrections to make. Please see 
[DD] inline.

On 2021-07-26, 9:16 PM, "Ron Bonica" 
mailto:rbonica=40juniper@dmarc.ietf.org>>
 wrote:

Gyan,

The design team was not chartered to select a winner. It was chartered to 
provide input to the WG.

AFAIKS, the WG still has the following tasks before it:


- To determine whether the all candidate solutions are compliant with 
existing BCP and PS drafts (particularly RFC 4291)
[DD] I answered this in another thread.


- To determine whether zero, one, or more candidate solutions should be 
advanced

- To determine which requirements are significant with regard to 
candidate advancement

Recall that the DT did not poll operators for requirements. They documented 
requirements as they understood them. Therefore, requirements may be skewed, 
reflecting the composition of the design team more than the requirements of the 
larger community.


[DD] Back in November (9 months ago) the requirements draft was reviewed at 
IETF 109 and significant changes were made based on operator feedback, 
incorporated and reviewed at IETF 110. We received feedback from operators on 
both SRv6 Based and SID summarization 
https://mailarchive.ietf.org/arch/msg/spring/1vaEUwW26GySsPhR1ljud1GeTWU/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/1vaEUwW26GySsPhR1ljud1GeTWU/__;!!NEt6yMaO-gk!UQWQRsqRW0TJU5rRuxOTHWATwHOVcvAr6vGWh-L1PTc2C36jQJVy_Y7XWzsyNkFr$>,
 among others.  The design team incorporated those and other changes into the 
document with unanimous consensus (including you Ron). Stating the requirements 
are not those of the larger community is not true.

Note: 5 of 7 design team members were co-authors of the CSID, GSID, or uSID 
documents.


[DD] This statement, in context of above, appears to undermine the design 
team's work.

Here is what I've observed:

  *   The design team members were chosen by the SPRING chairs - there are 3 of 
them, and I have a great deal of respect for them and their choice of DT 
members.
  *   The design team worked hard to produce requirements with the input of the 
SPRING WG, presenting at two IETF meetings, seeking and incorporating the 
changes asked for.
  *   The design team worked hard to produce analysis of each proposal (CSID, 
UIDSR, GSID, VSID) against the reviewed requirements.
  *   The requirements and analysis both had unanimous consensus of the design 
team.  This is a very high bar! The design team chair, Weiqiang, felt this 
would produce the most reliable result.  I think he was correct and while I 
struggled with this bar I thank him for his diligence.
  *   The drafts that design team members authored is irrelevant, given the 
process used for selection, unanimous consensus, and the lengthy WG review.
  *   We did good work to collaborate and reach consensus. This has given me 
the utmost respect for all my design team co-authors and the process used to 
produce these documents.

Darren


Ron





Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Monday, July 26, 2021 7:51 PM
To: Darren Dukes (ddukes) 
mailto:ddukes=40cisco@dmarc.ietf.org>>
Cc: SPRING WG mailto:spring@ietf.org>>
Subject: Re: [spring] SRv6 SID List compression

[External Email. Be cautious of content]


Dear DT,

Excellent work and many thanks to  the design team to come provide the detailed 
analysis of the 4 proposals and how they match up with the requirements.

>From the analysis it does sound like CSID is the choice by the DT

Re: [spring] SRv6 SID List compression

[Ron Bonica]

Gyan,

The design team was not chartered to select a winner. It was chartered to 
provide input to the WG.

AFAIKS, the WG still has the following tasks before it:


  *   To determine whether the all candidate solutions are compliant with 
existing BCP and PS drafts (particularly RFC 4291)
  *   To determine whether zero, one, or more candidate solutions should be 
advanced
  *   To determine which requirements are significant with regard to candidate 
advancement

Recall that the DT did not poll operators for requirements. They documented 
requirements as they understood them. Therefore, requirements may be skewed, 
reflecting the composition of the design team more than the requirements of the 
larger community.

Note: 5 of 7 design team members were co-authors of the CSID, GSID, or uSID 
documents.


Ron





Juniper Business Use Only
From: spring  On Behalf Of Gyan Mishra
Sent: Monday, July 26, 2021 7:51 PM
To: Darren Dukes (ddukes) 
Cc: SPRING WG 
Subject: Re: [spring] SRv6 SID List compression

[External Email. Be cautious of content]


Dear DT,

Excellent work and many thanks to  the design team to come provide the detailed 
analysis of the 4 proposals and how they match up with the requirements.

>From the analysis it does sound like CSID is the choice by the DT.

SRv6 compression & MSD issue is now finally solved!  Excellent news!!

Now it's just a matter of moving forward with CSID Adoption poll.

>From the analysis it does not seem there is any draft that is in close 2nd 
>place or a close call.

>From the analysis draft the two drafts that are combined to create CSID -> I 
>don't see it on the Spring WG Datatracker?

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02


The following mechanisms are proposed to compress the SRv6 SID list:



   o  CSID - 
[I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]
 - Describes

  two new SRv6 SID flavors, a combination of SID flavors from

  
[I-D.filsfils-spring-net-pgm-extension-srv6-usid]
 and

  
[I-D.cl-spring-generalized-srv6-for-cmpr]

   o  CRH - 
[I-D.bonica-6man-comp-rtg-hdr]
 - Requires two new routing

  header types and a label mapping technique.

   o  VSID - 
[I-D.decraene-spring-srv6-vlsid]
 - Defines a set of SID

  behaviors to access smaller SIDs within the SR header.

   o  UIDSR - 
[I-D.mirsky-6man-unified-id-sr]
 - Extends the SRH to carry

  MPLS labels or IPv6 addresses.


Below 2 drafts are combined to create CSID??

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10


https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03


Kind Regards

Gyan

On Mon, Jul 26, 2021 at 5:53 PM Darren Dukes (ddukes) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I'll paraphrase what I said in the call...

Today the design team presented 

[spring] The deferred compression requirement

[Ron Bonica]

Chairs,

The design team did not consider whether the candidate compression schemes 
comply with existing BCP and PS drafts. We agreed that the WG would take up 
this issue after the design team completed its work.

I think that there is a question as to whether the CSID solution complies with 
RFC 4291 and, therefore, RFC 8200. We should take up that discussion now.

As RFC 4291 is the product of the 6man WG, I believe that 6man should 
participate in that discussion.

With the chairs kind permission, I will kick off that discussion, copying 6man 
on the question.


 Ron





Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] operator requirements for draft-srcompdt-spring-compression-requirement

[Ron Bonica]

Martin,

In Section 4.2.4 (Metric), you say:

>  Metric: The compression mechanism fits into existing IPv6 address 
> structures. It does not require management of a new kind of number 
> resource that needs to be coordinated for all network domains that are 
> potentially involved.

Does this mean that it is OK to have a new kind of number, so long as it is not 
propagated across domain boundaries?

  Ron
  /speaking as an 
individual contributor
  / and not on 
behalf of the design team




Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Martin Horneffer
Sent: Wednesday, April 14, 2021 11:53 AM
To: Weiqiang Cheng ; spring@ietf.org
Cc: 'srcomp' 
Subject: Re: [spring] operator requirements for 
draft-srcompdt-spring-compression-requirement

[External Email. Be cautious of content]


Hi Weiqiang,

thank you for looking into it!

Concerning address aggregation and SID summarization you are probably
right: When keeping the reqirements generic 4.2.4 should cover the requirement 
of "address aggregation".
In my eyes, creating another company-wide concept for SID delegation and 
reservation as we once did for IPv6 addresses, which needs to take care of all 
requiements and growth potential of every single network domain and service 
area, looks like a nightmare. But technically you are perfetcly correct.

So please ignore point 4.3.5 from my suggestion.

Best regards, Martin

Am 12.04.21 um 04:23 schrieb Weiqiang Cheng:
> Hi Martin,
> Thanks a lot for your suggestions.
> Design team will discuss them and feedback you soon.
> We also hope WG members can discuss the comments together.
> A quick question, do you think whether Address Aggregation requirement has 
> been covered by existed "4.2.4. SID summarization" ?
>
> B.R.
> Weiqiang Cheng
>
>
>
> -邮件原件-
> 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Martin Horneffer
> 发送时间: 2021年4月7日 20:47
> 收件人: spring@ietf.org
> 主题: [spring] operator requirements for 
> draft-srcompdt-spring-compression-requirement
>
> Dear srcomp dt, and spring wg,
>
> thanks a lot for the enormous effort to collect and describe all the 
> requirements for compression mechanisms, and for already starting the 
> analysis! A true work of merit.
>
>   From an operator’s point of view I would like to add two 
> requirements that I believe to be crucial to any kind of new 
> overarching
> architecture: address management and address aggregation.
>
> In my eyes, SRv6 does have the great potential to allow a new 
> architectures that span many still separate network domains (access, 
> aggregation, backbone, service areas, etc) and greatly simplify and 
> streamline their operation. However, in order to allow this in an 
> already existing operator environment, I really see these two points 
> as essential.
>
> This probably has already been covered by Dirk’s mail below, and I 
> tried to make the point during the IETF109 session, but probably 
> wasn’t clear enough. I haven’t seen any discussion of it yet.
>
>
> In any case I tried to find a wording that might be suitable for 
> addition to the requirements document. There are of course many ways 
> to tackle the issue, and this is just one attempt. Please let me know 
> what you think of it.
>
> Best regards,
> Martin
>
>
> Proposed additions for draft-srcompdt-spring-compression-requirement:
>
> 4.3.4.  Number Resource Management
>
>  Description: The compression mechanism SHOULD fit into existing 
> IPv6 address structures. It SHOULD NOT require management of a new 
> kind of number resource that needs to be coordinated for all network 
> domains that potentially could be connected to each other. Network 
> domains rather take existing parts of their address space to provide 
> their local functions, while staying fully interoperable with all other 
> domains.
>
>  Rationale: In larger organizations different network domains (e.g.
> access, aggregation, backbone, service areas) are managed by different 
> organizational units. Number resources such as IP addresses and 
> numeric identifiers must be organized in a way, that a) makes sure 
> that every network domain gets enough resources (e.g. address space) 
> to meet its needs, and b) conflicts between domains are prevented. 
> Network operators have solved this problem for resources such as IPv4 
> and IPv6 addresses already and can relatively easily base new 
> technology on this. On the other hand introducing new types of number 
> resources might impose serious costs on all affected organizational 
> units and thus seriously impede the introduction of the related technology.
>
>  Metric: The compression mechanism fits into existing IPv6 address 
> structures. It does not require management of a new kind of number 
> resource that needs to be coordinated 

Re: [spring] [Srcomp] New drafts from SRCOMP design team

[Ron Bonica]

Rishabh,

Is Section 2 of the SR replication segment draft compliant with Section 2.7 of 
RFC 4291? Could it be brought into compliance by using the high order 16 bits 
that RFC 4291 recommends?

   Ron




Juniper Business Use Only
From: Srcomp  On Behalf Of Weiqiang Cheng
Sent: Tuesday, March 2, 2021 12:28 AM
To: 'Rishabh Parekh' 
Cc: src...@ietf.org; 'SPRING WG List' 
Subject: Re: [Srcomp] [spring] New drafts from SRCOMP design team

[External Email. Be cautious of content]

Hi Rishabh,
Thanks for your comments.
It is good point, and DT will consider the it in.

B.R.
Weiqiang Cheng

发件人: spring [mailto:spring-boun...@ietf.org] 代表 Rishabh Parekh
发送时间: 2021年2月27日 01:50
收件人: Weiqiang Cheng
抄送: src...@ietf.org; SPRING WG List
主题: Re: [spring] New drafts from SRCOMP design team

Weiqiang,
Text quoted below from the SPRING charter indirectly covers Point-to-Multipoint 
requirement which is addressed by SR Replication Segment draft 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/

New types of segments mapping to forwarding behaviour (e.g., local

ingress replication, local forwarding resources, a pre-existing

replication structure) if needed for new usages.
For the Point-to-Multipoint compression requirement, what exactly is "multicast 
address" in the Metric? Is this an IPv6 multicast address? If so, it really 
does not conform to SRv6 data plane.

I would rather consider the SRv6 Replication SID, described in the latest 
version of SR Replication segment draft, to be the Metric for measuring P2MP 
requirement. Maybe we should also consider adding it to SRv6 Functionality 
Section 4.2.1 of the compression requirements draft.

-Rishabh


On Thu, Feb 25, 2021 at 9:25 AM Weiqiang Cheng 
mailto:chengweiqi...@chinamobile.com>> wrote:
Hi All,
Two drafts have been submitted.  Please review them and any comments are 
welcomed.

Compression requirement draft -04 version provided two more requirements:

https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-04.txt

Compression analysis draft -00 provided a skeleton for the analysis of 4 
candidate proposals.
https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-analysis-00.txt

B.R.
Weiqiang
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Ron Bonica]

Hi Gyan,

In theory, it should map any END.DTM to  any MPLS label stack, regardless of 
the control plane.

  Ron




Juniper Business Use Only
From: Gyan Mishra 
Sent: Monday, February 15, 2021 12:18 AM
To: Ron Bonica 
Cc: Jeff Tantsura ; Loa Andersson ; 
spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Thanks Ron!

I really like the innovative idea.

Will this work with LDP v4 v6 to SRv6 interworking as well is my guess?

Kind Regards

Gyan

On Fri, Feb 12, 2021 at 12:04 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Gyan,

Control plane considerations are beyond the scope of this draft. That said, 
when I wrote the draft, I was thinking that the border nodes were ASBRs.


  Ron




Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, February 12, 2021 3:55 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Loa Andersson mailto:l...@pi.nu>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Hi Ron

This is an interesting  SR-MPLS to SRv6 interworking concept.

For an end to end LSP where you end up doing a translation on a border node 
doing the interworking pop of MPLS label stack and impose of SRv6 IPv6 header 
in one direction and POP of SRv6 IPv6 header and impose of MPLS label stack in 
the other direction, how does the LSP get stitched from ingress PE to egress PE 
FEC destination if the intermediate node in the path is a P node doing the 
translation interworking.  I think if the translation interworking node was an 
egress PE that is doing the ASBR function handoff seems plausible, but if it’s 
a P node as it appears in your example how would the LSP get stitched end to 
end.

Could this same concept be used for MPLS LDP fo SRv6 interworking as well.

Kind Regards

Gyan

On Tue, Feb 9, 2021 at 8:00 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Thanks Ron, couldn’t have explained it better.

Prefix SID (and the prefix associated with it) could be reachable over any 
interface participating in the topology,  depending on that topology structure, 
with topology changes, outgoing interface might change as well. Hence the 
outgoing interface is a runtime property of the top SID.

Loa - does this clarify?

Cheers,
Jeff
On Feb 9, 2021, 12:35 PM -0800, Ron Bonica 
mailto:rbon...@juniper.net>>, wrote:
Loa,

I think that Jeff means to say that " A SID instance is associated with SR-MPLS 
label stack. A label stack entry can be associated with a next hop. A recursive 
lookup may be required to derive the next hop from the topmost label stack 
entry."

Ron



Juniper Business Use Only

-Original Message-
From: Loa Andersson mailto:l...@pi.nu>>
Sent: Monday, February 8, 2021 11:51 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Ron Bonica mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Jeff,


On 08/02/2021 14:51, Jeff Tantsura wrote:
Hi Ron,

Very useful document, thanks!

Question wrt processing:
As described in the draft:
“A SID instance is associated with SR-MPLS label stack and outgoing interface.”

I’d think that outgoing interface would be recursively resolved based on the 
top SID (and could change based on topological semantics).
Could you please elaborate?

What exactly do yo mean by "recursively"?

/Loa

Thanks!


Cheers,
Jeff
On Feb 7, 2021, at 08:46, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:


Please review and comment


Juniper Business Use Only
-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky mailto:gregimir...@gmail.com>>; Peng 
Shaofu
mailto:peng.sha...@zte.com.cn>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Shaofu
Peng mailto:peng.sha...@zte.com.cn>>; Shraddha Hegde
mailto:shrad...@juniper.net>>; EXT- 
zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>
mailto:zhang.zh...@zte.com.cn>>
Subject: New Version Notification for
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name: draft-bonica-spring-srv6-end-dtm
Revision: 01
Title: The SRv6 END.DTM Segment Ty

[spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-03.txt

[Ron Bonica]

Folks,

The draft has been updated to address comments.

  Ron


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, February 12, 2021 3:53 PM
> To: Greg Mirsky ; Peng Shaofu
> ; Ron Bonica ; Shaofu Peng
> ; Shraddha Hegde ; EXT-
> zhang.zh...@zte.com.cn 
> Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-03.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-spring-srv6-end-dtm-03.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-spring-srv6-end-dtm
> Revision:   03
> Title:  The SRv6 END.DTM Endpoint Behavior
> Document date:  2021-02-12
> Group:  Individual Submission
> Pages:  7
> URL:  https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-03.txt
> Status:  https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm/
> Htmlized: https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-03
> Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-03
> 
> Abstract:
>This document describes a new SRv6 endpoint behavior, called END.DTM.
>END.DTM supports inter-working between SRv6 and SR-MPLS.  Like any
>endpoint behavior, END.DTM contains a function and arguments.  The
>function causes the processing node to decapsulate a packet, impose
>an SR-MPLS label stack and forward the packet.  The arguments
>determine SR-MPLS label stack contents.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Ron Bonica]

Gyan,

Control plane considerations are beyond the scope of this draft. That said, 
when I wrote the draft, I was thinking that the border nodes were ASBRs.


  Ron




Juniper Business Use Only
From: Gyan Mishra 
Sent: Friday, February 12, 2021 3:55 AM
To: Jeff Tantsura 
Cc: Loa Andersson ; Ron Bonica ; 
spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Hi Ron

This is an interesting  SR-MPLS to SRv6 interworking concept.

For an end to end LSP where you end up doing a translation on a border node 
doing the interworking pop of MPLS label stack and impose of SRv6 IPv6 header 
in one direction and POP of SRv6 IPv6 header and impose of MPLS label stack in 
the other direction, how does the LSP get stitched from ingress PE to egress PE 
FEC destination if the intermediate node in the path is a P node doing the 
translation interworking.  I think if the translation interworking node was an 
egress PE that is doing the ASBR function handoff seems plausible, but if it’s 
a P node as it appears in your example how would the LSP get stitched end to 
end.

Could this same concept be used for MPLS LDP fo SRv6 interworking as well.

Kind Regards

Gyan

On Tue, Feb 9, 2021 at 8:00 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Thanks Ron, couldn’t have explained it better.

Prefix SID (and the prefix associated with it) could be reachable over any 
interface participating in the topology,  depending on that topology structure, 
with topology changes, outgoing interface might change as well. Hence the 
outgoing interface is a runtime property of the top SID.

Loa - does this clarify?

Cheers,
Jeff
On Feb 9, 2021, 12:35 PM -0800, Ron Bonica 
mailto:rbon...@juniper.net>>, wrote:
Loa,

I think that Jeff means to say that " A SID instance is associated with SR-MPLS 
label stack. A label stack entry can be associated with a next hop. A recursive 
lookup may be required to derive the next hop from the topmost label stack 
entry."

Ron



Juniper Business Use Only

-Original Message-
From: Loa Andersson mailto:l...@pi.nu>>
Sent: Monday, February 8, 2021 11:51 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Ron Bonica mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Jeff,


On 08/02/2021 14:51, Jeff Tantsura wrote:
Hi Ron,

Very useful document, thanks!

Question wrt processing:
As described in the draft:
“A SID instance is associated with SR-MPLS label stack and outgoing interface.”

I’d think that outgoing interface would be recursively resolved based on the 
top SID (and could change based on topological semantics).
Could you please elaborate?

What exactly do yo mean by "recursively"?

/Loa

Thanks!


Cheers,
Jeff

On Feb 7, 2021, at 08:46, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:


Please review and comment


Juniper Business Use Only

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky mailto:gregimir...@gmail.com>>; Peng 
Shaofu
mailto:peng.sha...@zte.com.cn>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Shaofu
Peng mailto:peng.sha...@zte.com.cn>>; Shraddha Hegde
mailto:shrad...@juniper.net>>; EXT- 
zhang.zh...@zte.com.cn<mailto:zhang.zh...@zte.com.cn>
mailto:zhang.zh...@zte.com.cn>>
Subject: New Version Notification for
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name: draft-bonica-spring-srv6-end-dtm
Revision: 01
Title: The SRv6 END.DTM Segment Type
Document date: 2021-02-07
Group: Individual Submission
Pages: 7
URL: 
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F9ybUH5$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F9ybUH5$>
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-b>
onica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8ap
yYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8Oytsvgj$
Htmlized: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqs

[spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-02.txt

[Ron Bonica]

Folks,

The draft has been updated to reflect Takuya's and Jeff's comments.

   Ron


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Tuesday, February 9, 2021 3:59 PM
> To: Greg Mirsky ; Peng Shaofu
> ; Ron Bonica ; Shaofu Peng
> ; Shraddha Hegde ; EXT-
> zhang.zh...@zte.com.cn 
> Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-02.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-spring-srv6-end-dtm-02.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-spring-srv6-end-dtm
> Revision:   02
> Title:  The SRv6 END.DTM Endpoint Behavior
> Document date:  2021-02-09
> Group:  Individual Submission
> Pages:  7
> URL: https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-02.txt
> Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
> Htmlized:  
> https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
> Htmlized:   
> https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-02
> Diff: https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-02

Abstract:
>This document describes a new SRv6 endpoint behavior, called END.DTM.
>The END.DTM endpoint behavior supports inter-working between SRv6 and
>SR-MPLS.  Like any endpoint behavior, END.DTM contains a function and
>arguments.  The function causes the processing SRv6 node to remove an
>SRv6 header, impose an SR-MPLS label stack, and forward the packet to
>its next hop.  The arguments determine MPLS-label stack contents and
>the next hop.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Ron Bonica]

Takuya,

Thanks for the review. I agree with both of your comments and will update the 
draft to reflect them.

   Ron



Juniper Business Use Only

-Original Message-
From: Takuya Miyasaka  
Sent: Tuesday, February 9, 2021 2:38 AM
To: Ron Bonica ; spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Hi Ron,

I think this new SRv6 endpoint behavior is very useful to connect an
SRv6 island and an SR-MPLS island. I have two comments.

In this draft, you introduced the End.DTM as a new "segment type", but 
according to draft-ietf-spring-srv6-network-programming draft I think this 
should be "endpoint behavior".

Section.1 says "The arguments determine MPLS-label stack contents and Transport 
Class of the MPLS Tunnel." I was interested in this feature, but there is no 
detailed description in Section.4. Could you elaborate on this feature in the 
future version? I also want to clarify the meaning of "Transport Class of the 
MPLS Tunnel".

Thanks,
Takuya

On 2021/02/08 1:46, Ron Bonica wrote:
> Please review and comment
>
>
> Juniper Business Use Only
>
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Sunday, February 7, 2021 11:41 AM
>> To: Greg Mirsky ; Peng Shaofu 
>> ; Ron Bonica ; Shaofu 
>> Peng ; Shraddha Hegde ; 
>> EXT- zhang.zh...@zte.com.cn 
>> Subject: New Version Notification for 
>> draft-bonica-spring-srv6-end-dtm-01.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF 
>> repository.
>>
>> Name:   draft-bonica-spring-srv6-end-dtm
>> Revision:   01
>> Title:  The SRv6 END.DTM Segment Type
>> Document date:  2021-02-07
>> Group:  Individual Submission
>> Pages:  7
>> URL:   
>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7OtkjTdhLAJpHlv4kHi3tuo8igEK-KHid3Ers3apfxpz$
>> Status: 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo
>> nica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7OtkjTdh
>> LAJpHlv4kHi3tuo8igEK-KHid3Ers6XDGQs5$
>> Htmlized:  
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7OtkjTdhLAJpHlv4kHi3tuo8igEK-KHid3Ers7V73ouQ$
>> Htmlized:  
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7OtkjTdhLAJpHlv4kHi3tuo8igEK-KHid3Ers9Bc_0If$
>> Diff:  
>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-b
>> onica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7Otk
>> jTdhLAJpHlv4kHi3tuo8igEK-KHid3Ers3wHzB3_$
>>
>> Abstract:
>> This document describes a new SRv6 segment type, called END.DTM.  The
>> END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
>> Like any segment type, END.DTM contains a function and arguments.
>> The function causes the processing SRv6 node to remove an SRv6 header
>> and impose an SR-MPLS label stack.  The arguments determine MPLS-
>> label stack contents.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
> ___
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!WXJS7gHtTlKRKddVqvvm7OtkjTdhLAJpHlv4kHi3tuo8igEK-KH
> id3Ers37m7DaB$
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Ron Bonica]

Loa,

I think that Jeff means to say that " A SID instance is associated with SR-MPLS 
label stack. A label stack entry can be associated with a next hop. A recursive 
lookup may be required to derive the next hop from the topmost label stack 
entry."

Ron



Juniper Business Use Only

-Original Message-
From: Loa Andersson  
Sent: Monday, February 8, 2021 11:51 PM
To: Jeff Tantsura ; Ron Bonica 
Cc: spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


Jeff,


On 08/02/2021 14:51, Jeff Tantsura wrote:
> Hi Ron,
>
> Very useful document, thanks!
>
> Question wrt processing:
> As described in the draft:
> “A SID instance is associated with SR-MPLS label stack and outgoing 
> interface.”
>
> I’d think that outgoing interface would be recursively resolved based on the 
> top SID (and could change based on topological semantics).
> Could you please elaborate?

What exactly do yo mean by "recursively"?

/Loa
>
> Thanks!
>
>
> Cheers,
> Jeff
>
>> On Feb 7, 2021, at 08:46, Ron Bonica  
>> wrote:
>>
>> 
>> Please review and comment
>>
>>
>> Juniper Business Use Only
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org 
>>> Sent: Sunday, February 7, 2021 11:41 AM
>>> To: Greg Mirsky ; Peng Shaofu 
>>> ; Ron Bonica ; Shaofu 
>>> Peng ; Shraddha Hegde 
>>> ; EXT- zhang.zh...@zte.com.cn 
>>> 
>>> Subject: New Version Notification for 
>>> draft-bonica-spring-srv6-end-dtm-01.txt
>>>
>>> [External Email. Be cautious of content]
>>>
>>>
>>> A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
>>> has been successfully submitted by Ron Bonica and posted to the IETF 
>>> repository.
>>>
>>> Name:   draft-bonica-spring-srv6-end-dtm
>>> Revision:   01
>>> Title:  The SRv6 END.DTM Segment Type
>>> Document date:  2021-02-07
>>> Group:  Individual Submission
>>> Pages:  7
>>> URL:   
>>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F9ybUH5$
>>> Status: 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>>> onica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8ap
>>> yYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8Oytsvgj$
>>> Htmlized:  
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8F2zaLIO$
>>> Htmlized:  
>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8DZVjUN4$
>>> Diff:  
>>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-
>>> bonica-spring-srv6-end-dtm-01__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4t
>>> F8apyYbe9Xg2bqsA3kb6qY2F-3qbYIFrhF8CJWOgzv$
>>>
>>> Abstract:
>>>This document describes a new SRv6 segment type, called END.DTM.  The
>>>END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
>>>Like any segment type, END.DTM contains a function and arguments.
>>>The function causes the processing SRv6 node to remove an SRv6 header
>>>and impose an SR-MPLS label stack.  The arguments determine MPLS-
>>>label stack contents.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of 
>>> submission until the htmlized version and diff are available at 
>>> tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
>> ing__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3q
>> bYIFrhF8PggLsaR$
>
> ___
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!Xh8RUucGY-Dw_xFwM_vU4tF8apyYbe9Xg2bqsA3kb6qY2F-3qbY
> IFrhF8PggLsaR$
>

--

Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Ron Bonica]

Please review and comment


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Sunday, February 7, 2021 11:41 AM
> To: Greg Mirsky ; Peng Shaofu
> ; Ron Bonica ; Shaofu Peng
> ; Shraddha Hegde ; EXT-
> zhang.zh...@zte.com.cn 
> Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-spring-srv6-end-dtm
> Revision:   01
> Title:  The SRv6 END.DTM Segment Type
> Document date:  2021-02-07
> Group:  Individual Submission
> Pages:  7
> URL:   https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt
> Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
> Htmlized:  
> https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
> Htmlized:  https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01
> Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-01
> 
> Abstract:
>This document describes a new SRv6 segment type, called END.DTM.  The
>END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
>Like any segment type, END.DTM contains a function and arguments.
>The function causes the processing SRv6 node to remove an SRv6 header
>and impose an SR-MPLS label stack.  The arguments determine MPLS-
>label stack contents.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] PSP and USP uN Flavors

[Ron Bonica]

Pablo,

Assume the following packet:


  *   Destination address is a uSID container
  *   Next header is an SRH

In this case, you wouldn't process the SRH until you process every uSID in the 
uSID container. Do I have this much right?

So, if any uSID in the container specified the PSP or USP flavor, you would 
delete an SRH that has not yet been processed.

Do I have this right?

   Ron




Non-Juniper
From: spring  On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, September 9, 2020 4:13 AM
To: G. Sri Karthik Goud ; spring@ietf.org
Cc: Swamy SRK 
Subject: Re: [spring] PSP and USP uN Flavors

[External Email. Be cautious of content]

Hi Karthik,

Please see inline.

Cheers,
Pablo.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of G. Sri Karthik Goud
Sent: miércoles, 26 de agosto de 2020 0:30
To: spring@ietf.org
Cc: Swamy SRK mailto:swa...@juniper.net>>
Subject: [spring] PSP and USP uN Flavors

Folks,

In draft-filsfils-spring-net-pgm-extension-srv6-usid, a uN represents an 
instruction (END, END.T) instantiated on a node. Can that instruction have a 
PSP or USP flavor?
[PC] The uN behavior is a new behavior. This behavior is defined in 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-07#section-4.1.1
The uN behavior may be combined with the PSP, USP or USD flavors. Same applies 
to the uA behavior.
You have the full list of behaviors in Section 9 of the draft.

If so, wouldn't the PSP/USP cause an SRH that has not yet been processed to be 
deleted?
[PC] No. Leveraging the terminology defined in Section 2 of the draft: the 
PSP/USP/USD is only executed when you get to the Last uSID of the uSID 
Container.
Please have a look at the uN pseudocode in the latest revision of the draft 
(rev 7). I believe the pseudocode is clearer than in previous revisions.
Thanks, and let me know if unclear.

- Karthik



Non-Juniper
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

[Ron Bonica]

+1



Juniper Business Use Only
From: spring  On Behalf Of Alexander Vainshtein
Sent: Thursday, July 30, 2020 11:07 AM
To: bruno.decra...@orange.com
Cc: draft-hegde-spring-node-protection-for-sr-te-pa...@ietf.org; spring@ietf.org
Subject: Re: [spring] WG adoption call for 
draft-hegde-spring-node-protection-for-sr-te-paths

[External Email. Be cautious of content]

Bruno, and all,
I strongly support adoption of 
draft-hegde-spring-node-protection-for-sr-te-paths as a WG document.
>From my POV  in its current stage it goes far beyond the common requirements 
>for adoption:

  *   Addresses a real and important problem within the scope of the SPRING WG
  *   Represents an excellent start for a solution of this problem.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 3:25 PM
To: spring@ietf.org
Cc: 
draft-hegde-spring-node-protection-for-sr-te-pa...@ietf.org
Subject: [spring] WG adoption call for 
draft-hegde-spring-node-protection-for-sr-te-paths

Hi SPRING WG,

Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked 
for WG adoption.

Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by August 20th 2020. (*)

Could those who are willing to work on this document, please notify the list. 
That gives us an indication of the energy level in the working group to work on 
this.

Thanks,
Regards,
Bruno, Jim, Joel

[1] 
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07
(*) 3 weeks to account for the IETF meeting week and the august/summer period.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that is confidential and/or proprietary for the sole 
use of the intended recipient. Any review, disclosure, reliance or distribution 
by others or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[Ron Bonica]

Hello friend,

SRv6 and SRm6 contain the same information in their FIBs. The difference is 
that the FIBs are structured differently.

Are you assuming that a change in FIB structure constitutes a new forwarding 
plane. Can you find any text in the IPv6 specifications that support this 
assumption?

Exploring the other side of the coin, the RFC 4291 definition of an IPv6 
address is very different from draft-filsfilscheng-spring-srv6-srh-comp-sl-enc 
definition of a C-SID container. Yet both can be placed in the destination 
address field of an IPv6 header. Is this still IPv6, or have we created a new 
data plane?

 Ron




Juniper Business Use Only
From: Vasilenko Eduard 
Sent: Tuesday, June 30, 2020 3:21 AM
To: Ron Bonica ; Darren Dukes (ddukes) ; 
SPRING WG 
Subject: RE: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Hi Guru,
In my humble opinion statement that something compressed is not a new data 
plane could be a little wrong.
Genesis of the solution (all solutions comes from extension capabilities of 
IPv6) could only permit to tell that it is "the same protocol", or more precise 
"extension of the same protocol".
But if new forwarding table (with shorter labels) should be created in PFE - 
then it is probably new data plane. It occupies separate resources in data 
plane.
Eduard
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: 30 июня 2020 г. 5:59
To: Darren Dukes (ddukes) 
mailto:ddukes=40cisco@dmarc.ietf.org>>; 
SPRING WG mailto:spring@ietf.org>>
Subject: Re: [spring] New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt

Darren,

The 6man WG is responsible for exactly one data plane. That is, IPv6.

IPv6 is extensible. So, new Routing headers and Options can be defined  without 
creating a new data plane. That's the whole idea of IPv6 extensibility.. Do you 
believe new data planes were created when the following were defined:


  *   The NIMROD Routing header
  *   They Type 2 Routing header
  *   The RPL Routing header
  *   The Segment Routing Header

Also, the bullets under discussion have little to do with an "SRv6 Network 
Programming Overhead Analysis".

If your real goal is holistic comparison of SRm6 and 
draft-filfilscheng-srv6-srh-comp-sl-eng, I would be glad to work with you on 
that. But a holistic comparison should probably have representation from both 
sides. Otherwise, it is mere marketing.

Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) 
mailto:ddukes=40cisco@dmarc.ietf.org>>
Sent: Monday, June 29, 2020 9:33 PM
To: Ron Bonica mailto:rbon...@juniper.net>>; SPRING WG 
mailto:spring@ietf.org>>
Subject: Re: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Hi Ron. Thanks for reading the document.

You say about section 5:
> Also, many of the things that you say in that
> bullet list are blatantly false. For example,
> SRm6 does not introduce a new data plane.
> In is extremely orthodox IPv6.

SRm6 uses IPv6 for transport and it introduces a dataplane that maps 32 or 16 
bit identifiers to a behavior and IPv6 address. Every SRm6 node must use this 
new dataplane implementation.  This is correct.

I believe the bullets I listed are relevant when holistically considering the 
proposals.

Sincerely,
  Darren



From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: Saturday, June 27, 2020 7:44:47 PM
To: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>; SPRING 
WG mailto:spring@ietf.org>>
Subject: RE: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt


Darren,



Your draft purports to be an "SRv6 Network Programming Overhead Analysis".  As 
such, it should address overhead analysis and avoid:



  *   Topics that are orthogonal to overhead analysis
  *   The appearance of attempting to position one compression strategy over 
another for reasons other than overhead



So, I recommend that you make the following changes to Section 5:



  *   The sentence "The mapping proposal, [I-D.bonica-spring-sr-mapped-six], 
does not bring any compression benefit compared to SRv6-native compression 
methods [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]" gives the appearance 
of author bias. Please replaces it with a neutral sentence like, "The two  
proposals [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] 
[I-D.bonica-spring-sr-mapped-six] provide similar compression.
  *   You say that " The SRm6 proposal does have several deficiencies however, 
including:" None of these have anything to do with overhead analysis. They 
don't belong in this document.
  *   Al

Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[Ron Bonica]

Darren,

The 6man WG is responsible for exactly one data plane. That is, IPv6.

IPv6 is extensible. So, new Routing headers and Options can be defined  without 
creating a new data plane. That's the whole idea of IPv6 extensibility.. Do you 
believe new data planes were created when the following were defined:


  *   The NIMROD Routing header
  *   They Type 2 Routing header
  *   The RPL Routing header
  *   The Segment Routing Header

Also, the bullets under discussion have little to do with an "SRv6 Network 
Programming Overhead Analysis".

If your real goal is holistic comparison of SRm6 and 
draft-filfilscheng-srv6-srh-comp-sl-eng, I would be glad to work with you on 
that. But a holistic comparison should probably have representation from both 
sides. Otherwise, it is mere marketing.

Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Monday, June 29, 2020 9:33 PM
To: Ron Bonica ; SPRING WG 
Subject: Re: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Hi Ron. Thanks for reading the document.

You say about section 5:
> Also, many of the things that you say in that
> bullet list are blatantly false. For example,
> SRm6 does not introduce a new data plane.
> In is extremely orthodox IPv6.

SRm6 uses IPv6 for transport and it introduces a dataplane that maps 32 or 16 
bit identifiers to a behavior and IPv6 address. Every SRm6 node must use this 
new dataplane implementation.  This is correct.

I believe the bullets I listed are relevant when holistically considering the 
proposals.

Sincerely,
  Darren


________
From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: Saturday, June 27, 2020 7:44:47 PM
To: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>; SPRING 
WG mailto:spring@ietf.org>>
Subject: RE: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt


Darren,



Your draft purports to be an "SRv6 Network Programming Overhead Analysis".  As 
such, it should address overhead analysis and avoid:



  *   Topics that are orthogonal to overhead analysis
  *   The appearance of attempting to position one compression strategy over 
another for reasons other than overhead



So, I recommend that you make the following changes to Section 5:



  *   The sentence "The mapping proposal, [I-D.bonica-spring-sr-mapped-six], 
does not bring any compression benefit compared to SRv6-native compression 
methods [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]" gives the appearance 
of author bias. Please replaces it with a neutral sentence like, "The two  
proposals [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] 
[I-D.bonica-spring-sr-mapped-six] provide similar compression.
  *   You say that " The SRm6 proposal does have several deficiencies however, 
including:" None of these have anything to do with overhead analysis. They 
don't belong in this document.
  *   Also, many of the things that you say in that bullet list are blatantly 
false. For example, SRm6 does not introduce a new data plane. In is extremely 
orthodox IPv6.




Ron









Juniper Business Use Only

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Darren Dukes (ddukes)
Sent: Saturday, June 27, 2020 1:22 AM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Fw: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt



[External Email. Be cautious of content]



Hello SPRING working group



There has been lots of work done in SPRING to develop, combine and refine 
methods of reducing the overhead of the SRv6 SRH.  We have some good 
submissions of requirements, framework analysis but no direct comparisons of 
different methods.



This draft kicks off that conversation with a simple analysis comparing SRv6 
native compression available via 
draft-filsfilscheng-spring-srv6-srh-comp-sl-enc vs the mapped SRm6 proposal 
draft-bonica-spring-sr-mapped-six.





Thanks

  Darren







From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Saturday, June 27, 2020 1:00 AM
To: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>
Subject: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt



A new version of I-D, draft-dukes-spring-srv6-overhead-analysis-00.txt
has been successfully submitted by Darren Dukes and posted to the
IETF repository.

Name:   draft-dukes-spring-srv6-overhead-analysis
Revision:   00
Title:  SRv6 Network Programming Overhead Analysis
Document date:  2020-06-27
Group:  Individual Submission
Pages:  9
URL:
https:

Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[Ron Bonica]

Darren,

Your draft purports to be an "SRv6 Network Programming Overhead Analysis".  As 
such, it should address overhead analysis and avoid:


  *   Topics that are orthogonal to overhead analysis
  *   The appearance of attempting to position one compression strategy over 
another for reasons other than overhead

So, I recommend that you make the following changes to Section 5:


  *   The sentence "The mapping proposal, [I-D.bonica-spring-sr-mapped-six], 
does not bring any compression benefit compared to SRv6-native compression 
methods [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]" gives the appearance 
of author bias. Please replaces it with a neutral sentence like, "The two  
proposals [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] 
[I-D.bonica-spring-sr-mapped-six] provide similar compression.
  *   You say that " The SRm6 proposal does have several deficiencies however, 
including:" None of these have anything to do with overhead analysis. They 
don't belong in this document.
  *   Also, many of the things that you say in that bullet list are blatantly 
false. For example, SRm6 does not introduce a new data plane. In is extremely 
orthodox IPv6.


Ron





Juniper Business Use Only
From: spring  On Behalf Of Darren Dukes (ddukes)
Sent: Saturday, June 27, 2020 1:22 AM
To: SPRING WG 
Subject: [spring] Fw: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Hello SPRING working group

There has been lots of work done in SPRING to develop, combine and refine 
methods of reducing the overhead of the SRv6 SRH.  We have some good 
submissions of requirements, framework analysis but no direct comparisons of 
different methods.

This draft kicks off that conversation with a simple analysis comparing SRv6 
native compression available via 
draft-filsfilscheng-spring-srv6-srh-comp-sl-enc vs the mapped SRm6 proposal 
draft-bonica-spring-sr-mapped-six.


Thanks
  Darren



From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: Saturday, June 27, 2020 1:00 AM
To: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>
Subject: New Version Notification for 
draft-dukes-spring-srv6-overhead-analysis-00.txt


A new version of I-D, draft-dukes-spring-srv6-overhead-analysis-00.txt
has been successfully submitted by Darren Dukes and posted to the
IETF repository.

Name:   draft-dukes-spring-srv6-overhead-analysis
Revision:   00
Title:  SRv6 Network Programming Overhead Analysis
Document date:  2020-06-27
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-dukes-spring-srv6-overhead-analysis-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-dukes-spring-srv6-overhead-analysis/
Htmlized:   
https://tools.ietf.org/html/draft-dukes-spring-srv6-overhead-analysis-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis


Abstract:
   SRv6 network programming provides the framework for the best
   compression of an IPv6 header within an SR domain.  This document
   provides the analysis to illustrate this fact.


The IETF Secretariat
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Spring SR question??

[Ron Bonica]

Jeff,

I'm not sure that is what Gyan was asking. He can clarify.

I think Gyan was asking about an environment where:


  *   SR-MPLS runs directly over ethernet. SR-MPLS is not encapsulated in IP or 
UDP over IP
  *   The SR-MPLS signaling protocol (IS-IS or OSPFv3) does not required IPv4 
to be enabled on the network.

   Ron




Juniper Business Use Only
From: Jeff Tantsura 
Sent: Tuesday, June 23, 2020 7:30 PM
To: Ron Bonica ; Gyan Mishra 
Cc: SPRING WG 
Subject: Re: [spring] Spring SR question??

[External Email. Be cautious of content]

Gyan,

In SR-MPLS, either over IPv4 or IPv6 the data-plane is MPLS (rfc8660)
If MPLS is tunneled over IP, e.g MPLS over GRE, MPLS over UDP, etc, then 
data-plane is that of outer encapsulation - rfc8663 as the best example, e.g 
outer header would be IPv4/IPv6+UDP
Since bindings (SIDs) need to be distributed, you'd need a label distribution 
protocol, with IPv6 that would be IS-IS, OSPFv3 or BGP (or  controller based).
Vendor support for that is rather limited, I don't recall any.
Other option to distribute label bindings over IPv6 would be LDPv6 + v6 IGP, I 
recall Junos implementation, there could be more.
There's quite interesting discussion on NANOG - 
https://mailman.nanog.org/pipermail/nanog/2020-June/208111.html

Hope this helps

Cheers,
Jeff
On Jun 23, 2020, 1:52 PM -0700, Gyan Mishra 
mailto:hayabusa...@gmail.com>>, wrote:


Thanks Ron!

Gyan

On Tue, Jun 23, 2020 at 3:51 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Gyan,

You can signal SR-MPLS over a network that has IPv6 enabled, but does not have 
IPv4 enabled.

   Ron




Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Tuesday, June 23, 2020 1:20 PM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Spring SR question??

[External Email. Be cautious of content]


All

SR-MPLS utilizes IPv4 data plane and and can service v4 v6 edges  6to4 softwire 
mesh framework from the VPN overlay aspect..

Can SR-MPLS use IPV6 data plane?

Reason why I am asking is that it is very simple to get from LDPv4 core to 
SR-MPLS core.

However if you have an existing brown field SP core and your end goal is to get 
to SRv6 - how can you easily get there.

So my thoughts are you can use SR-MPLS as a stepping stone so to speak to get 
to SRv6.

To that end you could use Greg Mirsky draft of tunneling SR-MPLS in SRV6 
interoperability and use other inter operability drafts.

But let's say you prefer to get from point A go point B seamlessly and native 
naturally without any translation.

An analogy would be migratory to IPV6 instead of using translation technology 
tunnels you dual stand the entire network and use ds-lite or LSN or 6RD to 
close the gap.

So my thoughts on getting to the "end state" SRv6 are we follows:

MPLS LDPv4

MPLS LDPv6

SR-MPLS v6

Once you have a v6 core and you have decommissioned LDPv6 you now have the v6 
data plan ready to go to get to SRv6

SRv6

Only caveat with this idea is I am not sure if SR-MPLS supports IPv6 data plane 
v6 label binding.


Kind Regards

Gyan

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q4s7bsLfxzuPcWXIRDIeAIPQEmMceA3IXDq3kMe-U3ICOTolz45wy2DnuOsEl42h$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia 
Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail=g__;KysrJSUrKys!!NEt6yMaO-gk!SHgdOi2pmbJVCHxRRVvni6kYfYGIoIdLPnbcZXH6p4R9FplXVzPc_t4OTWIy4o8f$>
Silver Spring, 
MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail=g__;KysrJSUrKys!!NEt6yMaO-gk!SHgdOi2pmbJVCHxRRVvni6kYfYGIoIdLPnbcZXH6p4R9FplXVzPc_t4OTWIy4o8f$>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!SHgdOi2pmbJVCHxRRVvni6kYfYGIoIdLPnbcZXH6p4R9FplXVzPc_t4OTV_RjKzI$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Spring SR question??

[Ron Bonica]

Gyan,

You can signal SR-MPLS over a network that has IPv6 enabled, but does not have 
IPv4 enabled.

   Ron




Juniper Business Use Only
From: spring  On Behalf Of Gyan Mishra
Sent: Tuesday, June 23, 2020 1:20 PM
To: SPRING WG 
Subject: [spring] Spring SR question??

[External Email. Be cautious of content]


All

SR-MPLS utilizes IPv4 data plane and and can service v4 v6 edges  6to4 softwire 
mesh framework from the VPN overlay aspect.

Can SR-MPLS use IPV6 data plane?

Reason why I am asking is that it is very simple to get from LDPv4 core to 
SR-MPLS core.

However if you have an existing brown field SP core and your end goal is to get 
to SRv6 - how can you easily get there.

So my thoughts are you can use SR-MPLS as a stepping stone so to speak to get 
to SRv6.

To that end you could use Greg Mirsky draft of tunneling SR-MPLS in SRV6 
interoperability and use other inter operability drafts.

But let's say you prefer to get from point A go point B seamlessly and native 
naturally without any translation.

An analogy would be migratory to IPV6 instead of using translation technology 
tunnels you dual stand the entire network and use ds-lite or LSN or 6RD to 
close the gap.

So my thoughts on getting to the "end state" SRv6 are we follows:

MPLS LDPv4

MPLS LDPv6

SR-MPLS v6

Once you have a v6 core and you have decommissioned LDPv6 you now have the v6 
data plan ready to go to get to SRv6

SRv6

Only caveat with this idea is I am not sure if SR-MPLS supports IPv6 data plane 
v6 label binding.


Kind Regards

Gyan

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

[Ron Bonica]

Support.

I would be willing to work on the draft.

  Ron



Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Monday, June 22, 2020 10:46 AM
To: spring@ietf.org
Subject: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

[External Email. Be cautious of content]


Hi SPRING WG,

Authors of draft-voyer-spring-sr-replication-segment [1] have asked for WG 
adoption.

Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by July 6th 2020.

Could those who are willing to work on this document, please notify the list. 
That gives us an indication of the energy level in the working group to work on 
this.

As a reminder, the call for IPR has been done last November. [2]

Thanks,
Regards,
Bruno, Jim, Joel

[1] 
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment__;!!NEt6yMaO-gk!Rnz-sCXB_TD-L853wHkZ8EFy-OUaViuew8u9z1bVY_s-FoheraiNwRO7nlyYHYJm$
[2] 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/tW-HHK7QzCw3ZBbFD0Dl7Eszd3k/__;!!NEt6yMaO-gk!Rnz-sCXB_TD-L853wHkZ8EFy-OUaViuew8u9z1bVY_s-FoheraiNwRO7ntxpGP3W$


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Rnz-sCXB_TD-L853wHkZ8EFy-OUaViuew8u9z1bVY_s-FoheraiNwRO7nqAhRnsB$

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Darren,

Will the SID defined in RFC 8754 appear in the IANA SRv6 Endpoint Behavior 
Sub-registry? If not, can it be implemented?


   Ron




Juniper Business Use Only
From: Darren Dukes (ddukes) 
Sent: Monday, June 15, 2020 10:17 PM
To: Ron Bonica ; Aijun Wang ; 
i...@ietf.org; spring@ietf.org
Subject: Re: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Ron.

The SID described in RFC8754 is fully described there.

The SIDs in draft-ietf-spring-SRv6-network-programming are fully defined in 
that document.

Darren


From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Sent: Monday, June 15, 2020 3:08:12 PM
To: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>; Aijun 
Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf..org<mailto:i...@ietf.org> mailto:i...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org> 
mailto:spring@ietf.org>>
Subject: RE: About the upper layer header processing in RFC8754(SRH)


Darren,



Does the SID described in RFC 8754 represent any of the SIDs in the Network 
Programming Draft? In any other document?



  
Ron





Juniper Business Use Only

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: About the upper layer header processing in RFC8754(SRH)



[External Email. Be cautious of content]



Hello Aijun.



No update to rfc8754 is necessary. Rfc8754 was written so new sids can be 
defined in other documents independently.



section 4.3.1 says:

This document and section define a single SRv6 SID.  Future documents

   may define additional SRv6 SIDs.  In such a case, the entire content

   of this section will be defined in that document.





Thanks

  Darren

  (Written on mobile)





From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Aijun Wang mailto:wang...@chinatelecom.cn>>
Sent: Sunday, June 14, 2020 10:15 PM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)



Hi, Folks:

RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjvxKIgrBz$>)
 describes the process of upper layer header as the followings:

IF (Upper-layer Header is IPv4 or IPv6) and

   local configuration permits {

 Perform IPv6 decapsulation

 Resubmit the decapsulated packet to the IPv4 or IPv6 module

   }

   ELSE {

   ..

}

And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjv0iiulaO$>),
 one new Ethernet Next Header Type(143) is proposed.



Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?



Best Regards



Aijun Wang

China Telecom


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Mark, Robert,

I will be in the club car of that train, enjoying a few shots of fernet branca.


 Ron




Juniper Business Use Only
From: Robert Raszuk 
Sent: Monday, June 15, 2020 6:04 PM
To: Mark Smith 
Cc: Ron Bonica ; Aijun Wang ; 
spring@ietf.org; i...@ietf.org
Subject: Re: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hey Mark,

Thank you for presenting your house architectural perspective.

Mine is much simpler ... I compare IPv6 128 bits of address to a train.

First 64 bits is a locomotive and undercarriage which we better leave alone.

However what goes into the remaining 64 bits are passengers travelling along. 
As such some may be just tourists, some may be monks having completely 
different missions in life. Yet another set may be gold miners etc ... I really 
do not see a need to redo the train in general just to accommodate different 
types of passengers to travel along. IMHO there is a room there for all of the 
above.

Sure changing ethertype and designing new tracks is a very attractive option. 
So is shortening the train engine to reduce the overhead - and I do like those 
(in fact proposed some of this already both publicly and privately), but Ron's 
mail is a bit shooting in between.

Anyhow I will leave it at that here,

Best,
R.

On Mon, Jun 15, 2020 at 11:52 PM Mark Smith 
mailto:markzzzsm...@gmail.com>> wrote:
On Tue, 16 Jun 2020 at 07:31, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
>
> Hi Ron,
>
> True !
>
> But pls do not take my response as an attempt to derail your shot. It was 
> rather a delicate attempt to put it on the right tracks towards the truth 
> target.
>

The IPv6 addressing model is 25 years old, going by the publication
date of RFC 1881 (1995).

IPv6 is like a 25 year old house. The purpose of some rooms is
flexible or somewhat flexible - a bedroom can be turned into a study,
or, depending on where it is located, a lounge room can be used as a
bedroom.

Other rooms in the house are fixed purpose and either are impossible
to change, or cannot be changed without a massive expense. It is
almost impossible to effectively change a kitchen into a bedroom, or a
bathroom into a kitchen.

At some point the house can't effectively be changed, and it is better
to design a new house. IPv6 isn't a house that is on the drawing board
any more, or is a house that is early in its construction such that
rooms' functions can be easily changed with minimal consequences.

If SPRING want a new forwarding architecture and a new addressing
architecture, then a new house needs to be designed.

Regards,
Mark.

> Best,
> Robert.
>
> On Mon, Jun 15, 2020 at 11:26 PM Ron Bonica 
> mailto:rbon...@juniper.net>> wrote:
>>
>> Robert,
>>
>>
>>
>> While this is an interesting question, it is orthogonal to the question that 
>> I posed to Darren.
>>
>>
>>
>>Ron
>>
>>
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> From: Robert Raszuk mailto:rob...@raszuk.net>>
>> Sent: Monday, June 15, 2020 3:33 PM
>> To: Ron Bonica mailto:rbon...@juniper.net>>
>> Cc: Darren Dukes (ddukes) mailto:ddu...@cisco.com>>; Aijun 
>> Wang mailto:wang...@chinatelecom.cn>>; 
>> i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
>> Subject: Re: About the upper layer header processing in RFC8754(SRH)
>>
>>
>>
>> [External Email. Be cautious of content]
>>
>>
>>
>> Hi Ron,
>>
>>
>>
>> I think this is not the question of RFC 8754.
>>
>>
>>
>> To me (and trust me I am not alone) this is much more of the question what 
>> IPv6 address means. How flexible we can use all bits regardless if we are 
>> talking SRv6 or not.
>>
>>
>>
>> Do we think that 
>> https://tools.ietf.org/html/rfc4291<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291__;!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tAuWwMLF$>
>>  section 2.5 still holds ? Do we need to keep stretching notion of interface 
>> to logical interfaces mapped to functions ?
>>
>>
>>
>> Then take projects completely unrelated to segment routing ... don't we see 
>> evident that we can encode a lot of useful information in the lowest 
>> significant bits of the IPv6 address without each time proposing new RH ?
>>
>>
>>
>> Best,
>>
>> R.
>>
>>
>>
>>
>>

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Robert,

While this is an interesting question, it is orthogonal to the question that I 
posed to Darren.

   Ron




Juniper Business Use Only
From: Robert Raszuk 
Sent: Monday, June 15, 2020 3:33 PM
To: Ron Bonica 
Cc: Darren Dukes (ddukes) ; Aijun Wang 
; i...@ietf.org; spring@ietf.org
Subject: Re: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Ron,

I think this is not the question of RFC 8754.

To me (and trust me I am not alone) this is much more of the question what IPv6 
address means. How flexible we can use all bits regardless if we are talking 
SRv6 or not.

Do we think that 
https://tools.ietf.org/html/rfc4291<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5ltmCnmb$>
 section 2.5 still holds ? Do we need to keep stretching notion of interface to 
logical interfaces mapped to functions ?

Then take projects completely unrelated to segment routing ... don't we see 
evident that we can encode a lot of useful information in the lowest 
significant bits of the IPv6 address without each time proposing new RH ?

Best,
R.



On Mon, Jun 15, 2020 at 9:08 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Darren,

Does the SID described in RFC 8754 represent any of the SIDs in the Network 
Programming Draft? In any other document?

  
Ron



Juniper Business Use Only
From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hello Aijun.

No update to rfc8754 is necessary. Rfc8754 was written so new sids can be 
defined in other documents independently.

section 4.3.1 says:

This document and section define a single SRv6 SID.  Future documents

   may define additional SRv6 SIDs.  In such a case, the entire content

   of this section will be defined in that document.


Thanks
  Darren
  (Written on mobile)


From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Aijun Wang mailto:wang...@chinatelecom.cn>>
Sent: Sunday, June 14, 2020 10:15 PM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjvxKIgrBz$>)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjv0iiulaO$>),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom


IETF IPv6 working group mailing list
i...@ietf.org<mailto:i...@ietf.org>
Administrative Requests: 
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5gomzxK4$>

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Darren,

Does the SID described in RFC 8754 represent any of the SIDs in the Network 
Programming Draft? In any other document?

  
Ron



Juniper Business Use Only
From: ipv6  On Behalf Of Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang ; i...@ietf.org; spring@ietf.org
Subject: Re: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hello Aijun.

No update to rfc8754 is necessary. Rfc8754 was written so new sids can be 
defined in other documents independently.

section 4.3.1 says:

This document and section define a single SRv6 SID.  Future documents

   may define additional SRv6 SIDs.  In such a case, the entire content

   of this section will be defined in that document.


Thanks
  Darren
  (Written on mobile)


From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Aijun Wang mailto:wang...@chinatelecom.cn>>
Sent: Sunday, June 14, 2020 10:15 PM
To: i...@ietf.org; 
spring@ietf.org
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Hi Jingrong,

I have found the text. (It was in my SPRING mailbox).

A much shorter update may suffice. Does the following work for you?

OLD>
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}

 IF (Upper-layer Header is IPv4 or IPv6 or Ethernet or ICMP) and
   local configuration permits {
 Perform IPv6 decapsulation
 Submit the newly exposed payload to the appropriate processing module
   }
   ELSE {
   ..
}


Sent: Monday, June 15, 2020 11:10 AM
To: Ron Bonica ; Aijun Wang ; 
i...@ietf.org; spring@ietf.org
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Ron,
Agreed ICMP is an upper-layer header that should be consistent with the 
SRv6-OAM draft [1], and I guess you may have also noticed the same.
Please see the proposed text I have just posted.

Regards,
Jingrong

[1] https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-05


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Monday, June 15, 2020 9:54 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spr...@ietf..org>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Aijun, Jingrong,

Could the upper-layer header also be ICMP, as in a ICMP Echo message?

Ron




Juniper Business Use Only
From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as 
well as some other text in SRv6-PGM section 4.1 (and some related sections) I 
have observed  about the Upper-layer processing for further discussion.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKhFgaBkD$>)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKiVOq5HR$>),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Hi Jingrong,

Where did you post the text?

 Ron




Juniper Business Use Only
From: Xiejingrong (Jingrong) 
Sent: Monday, June 15, 2020 11:10 AM
To: Ron Bonica ; Aijun Wang ; 
i...@ietf.org; spring@ietf.org
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Ron,
Agreed ICMP is an upper-layer header that should be consistent with the 
SRv6-OAM draft [1], and I guess you may have also noticed the same.
Please see the proposed text I have just posted.

Regards,
Jingrong

[1] https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-05


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Monday, June 15, 2020 9:54 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spr...@ietf..org>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Aijun, Jingrong,

Could the upper-layer header also be ICMP, as in a ICMP Echo message?

Ron




Juniper Business Use Only
From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as 
well as some other text in SRv6-PGM section 4.1 (and some related sections) I 
have observed  about the Upper-layer processing for further discussion.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKhFgaBkD$>)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKiVOq5HR$>),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Ron Bonica]

Aijun, Jingrong,

Could the upper-layer header also be ICMP, as in a ICMP Echo message?

Ron




Juniper Business Use Only
From: ipv6  On Behalf Of Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang ; i...@ietf.org; spring@ietf.org
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as 
well as some other text in SRv6-PGM section 4.1 (and some related sections) I 
have observed  about the Upper-layer processing for further discussion.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org; 
spring@ietf.org
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Leadership change

[Ron Bonica]

Congratulations to Jim and Joel. And thanks to Rob for his service.

  Ron



Juniper Business Use Only

-Original Message-
From: spring  On Behalf Of Martin Vigoureux
Sent: Sunday, June 14, 2020 4:25 PM
To: spring@ietf.org
Cc: 6...@ietf.org; int-...@ietf.org; bruno.decra...@orange.com; 
 ; Rob Shakir ; James 
Guichard ; Joel M. Halpern 

Subject: [spring] Leadership change

[External Email. Be cautious of content]


WG,

Rob had decided to step down as chair some time ago. There hasn't been any 
formal communication on that so I'd like, first, to thank Rob for his work and 
dedication to the group. Thank you very much Rob.

Since that time, I have been actively looking for one (or two) person(s) to 
replace him. This has proven to be a very challenging endeavour!

But it has finally came to an end.

I am pleased to inform you that I have appointed Jim Guichard and Joel Halpern 
as co-chairs of SPRING WG, alongside Bruno.
Thank you Jim, Thank you Joel, and thank you Bruno.


Martin
as AD for SPRING

___
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!R1s4USu8Opuele_xSzXAaZw5oSYU92exFRRIKonXBIXTZgeCYrzBdzaLkc1Vfnmo$

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Weibin,

Inline…..

 Ron




Juniper Business Use Only
From: Wang, Weibin (NSB - CN/Shanghai) 
Sent: Thursday, May 28, 2020 10:35 AM
To: Ketan Talaulikar (ketant) ; Ron Bonica 
; Joel M. Halpern 
Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]

Hi Ron,

After reading through many mails related to CRH in list, I found all CRH-SIDs 
(allocated to prefix-sid and Adj-sid) 
are of local significance in fact, its operation actually is not same as MPLS 
Label nor SR-MPLS label (such as domain-wide prefix SID/label), all CRH-SIDs 
are locally allocated by node itself based on local FIB6, independent of other 
CRH-SID allocated by other nodes in CRH domain; so every node (Maybe except  
ingress PE of CRH domain)  has no useful to learn other SIDs allocated by other 
nodes by IGP-extension advertising. Its deployment must have controller 
(considering dynamic mechanism), the controller learn all CRH-SIDs from each 
node to program the source path under path calculation requirement from ingress 
PE.

[RB] Absolutely correct !!


I suggested you should describe more detail about how to create CRH-SID entry 
(in CRH-FIB) in this CRH draft, is it based on local FIB6, if it is, how to do 
synchronization between CRH-FIB and FIB6?

[RB] In some deployment scenarios, the IPv6 FIB and the CRH-FIB are populated 
by an IGP. Please review and comment on the IS-IS CRH 
document<https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/>.
 I am excited to collaborate with you on that .

[RB] In other deployment scenarios, the IPv6 FIB and / or the CRH-FIB are 
populated by a controller. If you are interested in that scenario, again, we 
would be excited to collaborate with you.

   Ron


Above is my understanding, if not right,pls correct me.

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: 2020年5月28日 19:46
To: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>;
 Joel M. Halpern mailto:j...@joelhalpern.com>>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH


Hi Ron,



Some of the operators may not care about the SR name, but it is clear to me 
that the proposal in the CRH draft is a subset of Segment Routing (i.e. a 
reduced portion of Spring Architecture) that only supports prefix and adjacency 
SIDs as indicated by the two "forwarding methods".



https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$>


   o  Forward the packet to the next-hop along the least-cost path to >>> 
Prefix SID
  the next segment endpoint.

   o  Forward the packet through a specified interface to the next >>> 
Adjacency SID
  segment endpoint.



Given the use of mapping IDs and mapping FIB, the proposal is comparable more 
to SR-MPLS than SRv6. It is better to do a holistic analysis of any proposal 
such as CRH that is introducing an MPLS label like mapping construct into IPv6 
architecture - doing so should be considered as a significant change to IPv6.



Thanks,

Ketan



-Original Message-

From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>

Sent: 25 May 2020 21:14

To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Joel 
M. Halpern mailto:j...@joelhalpern.com>>

Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>

Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH



Ketan,



It would not be fair to say that these operators  "wish to deploy a Traffic 
Engineering solution using a subset of Segment Routing".



It would be fair to say that these operators  "wish to deploy IPv6 Traffic 
Engineering".  Some of these operators don't care about SR. Some are actively 
averse to SRv6. All they want is a Routing header.



 Ron















Juniper Business Use Only



-Original Message-

From: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>

Sent: Monday, May 25, 2020 5:21 AM

To: Ron Bonica mailto:rbon...@juniper.net>>; Joel M. 
Halpern mailto:j...@joelhalpern.com>>

Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.or

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Ron Bonica]

Ketan,

Please take a look at the version of the draft that we are reviewing. Values 
0-15 are no longer reserved.

 Ron




Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline ; Zafar Ali (zali) 
Cc: Ron Bonica ; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]


Sometimes a known devil is better than an unknown one.



I think we need to be very careful in considering the introduction of a new 
label/ID mapping technology into IPv6 Routing and it's ramifications.



https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-5.1__;Iw!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BMV7uEIv$>


   The maximum 16-bit SID value is 65,535.  Because SIDs 0 through 15
   are reserved for future use, a 16-bit SID offers 65,520 usable
   values.

   The maximum 32-bit SID value is 4,294,967,295.  Because SIDs 0
   through 15 are reserved for future use, a 32-bit SID offers
   4,294,967,280 usable values.



This is the same as 
https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BOmRmTOF$>



So is this, then in fact, an attempt to reinvent MPLS in a new avatar?



While some are talking about the CRH proposal as a brick, I see it as a tip of 
an iceberg. It is not just a new RH - it has significant impact across routing 
and ops areas. I would think one would expect a BoF for something like this? 
Therefore the request for proper documentation of the applicability, use-cases 
and architecture and their presentation (that too in the right areas/WGs) for 
the proper evaluation of this proposal.



Thanks,

Ketan





-Original Message-
From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) 
mailto:zali=40cisco....@dmarc.ietf.org>>
Cc: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>;
 spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?



There are actual, meaningful differences to be contemplated; folks with no 
operational MPLS in there networks might not want to be forced to start.





On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) 
mailto:zali=40cisco@dmarc.ietf.org>> wrote:

>

> Fred,

>

>

>

> Is there any IETF requirement document for OMNI and AERO (I am sorry I am not 
> aware of the technology but very much interested in learning)?

>

> Do we have some documents describing the scale you would need?

>

> Have the associated WG analyzed existing solutions?

>

> Have they feed the results of the above to 6man WG?

>

>

>

> All other routing header types have had requirements and designs from 
> dedicated working groups with expertise in the area.

>

> Why should CRH be an exception, especially when there are multiple competing 
> solutions in 6man and Spring?

>

>

>

> Thanks

>

>

>

> Regards ... Zafar

>

>

>

> From: "Templin (US), Fred L" 
> mailto:fred.l.temp...@boeing.com>>

> Date: Wednesday, May 27, 2020 at 4:33 PM

> To: Andrew Alston 
> mailto:andrew.als...@liquidtelecom.com>>, 
> Ron Bonica

> mailto:rbonica=40juniper@dmarc.ietf.org>>,
>  "Zafar Ali (zali)"

> mailto:z...@cisco.com>>, "Henderickx, Wim (Nokia - 
> BE/Antwerp)"

> mailto:wim.henderi...@nokia.com>>, Sander Steffann 
> mailto:san...@steffann.nl>>

> Cc: "spring@ietf.org<mailto:spring@ietf.org>" 
> mailto:spring@ietf.org>>, 6man 
> <6...@ietf.org<mailto:6...@ietf.org>>

> Subject: RE: Long-standing practice of due-diligence is expected - Re: 
> [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

>

>

>

> As I said, I want to use CRH for OMNI and AERO; I don't want the term

> "MPLS" to appear

>

> either in my documents or in any documents mine cite. The 16-bit CRIDs

> in CRH are very

>

> handy for coding ULA Subnet Router Anycast addresses such as

> fd80::/16, fd81::/16,

>

> fd82::/16, etc., and the 32-bit CRIDs are very handy for coding the

> admini

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Ketan,

Neither of these forwarding methods are unique to SR. In Section 3.1 of RFC 
791, you will see that IPv4 had a Strict Source Route Option and a Loose Source 
Route Option. These predate SR by roughly twenty-five years.


 Ron



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Thursday, May 28, 2020 7:46 AM
To: Ron Bonica ; Joel M. Halpern 
Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]


Hi Ron,



Some of the operators may not care about the SR name, but it is clear to me 
that the proposal in the CRH draft is a subset of Segment Routing (i.e. a 
reduced portion of Spring Architecture) that only supports prefix and adjacency 
SIDs as indicated by the two "forwarding methods".



https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!WUUoiYhNiQq44bqITjU9p16KKdON00tbtfOIgQoDmKHLycmNLLtVobJe9BtxN6V1$>


   o  Forward the packet to the next-hop along the least-cost path to >>> 
Prefix SID
  the next segment endpoint.

   o  Forward the packet through a specified interface to the next >>> 
Adjacency SID
  segment endpoint.



Given the use of mapping IDs and mapping FIB, the proposal is comparable more 
to SR-MPLS than SRv6. It is better to do a holistic analysis of any proposal 
such as CRH that is introducing an MPLS label like mapping construct into IPv6 
architecture - doing so should be considered as a significant change to IPv6.



Thanks,

Ketan



-Original Message-

From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>

Sent: 25 May 2020 21:14

To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Joel 
M. Halpern mailto:j...@joelhalpern.com>>

Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>

Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH



Ketan,



It would not be fair to say that these operators  "wish to deploy a Traffic 
Engineering solution using a subset of Segment Routing".



It would be fair to say that these operators  "wish to deploy IPv6 Traffic 
Engineering".  Some of these operators don't care about SR. Some are actively 
averse to SRv6. All they want is a Routing header.



 Ron















Juniper Business Use Only



-Original Message-

From: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>

Sent: Monday, May 25, 2020 5:21 AM

To: Ron Bonica mailto:rbon...@juniper.net>>; Joel M. 
Halpern mailto:j...@joelhalpern.com>>

Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>

Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH



[External Email. Be cautious of content]





Hi Ron,



Thanks for that clarification.



I note that you are not anymore saying "Are not interested in SR" like you had 
mentioned before the WG adoption call : 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>



So, would it be fair to say that the operator that you are referring to below, 
wishes to deploy a Traffic Engineering solution using a subset of Segment 
Routing (i.e. a reduced portion of Spring Architecture) that only supports 
prefix and adjacency SIDs as indicated by the two "forwarding methods" that are 
referred to in draft-bonica-6man-comp-rtg-hdr?



Thanks,

Ketan



-Original Message-

From: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>

Sent: 25 May 2020 09:03

To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Joel 
M. Halpern mailto:j...@joelhalpern.com>>

Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>

Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH



Ketan,



Please consider an operator who:



- Wants a way to steer IPv6 packets through a specified path that includes many 
nodes (>8)

- Does not want any of the following:

- A new VPN encapsulation technique

- 

Re: [spring] Limited domains ...

[Ron Bonica]

Brian,

I'm glad you brought this up, because I certainly have been thinking it. 

  Ron



Juniper Business Use Only

-Original Message-
From: Brian E Carpenter  
Sent: Wednesday, May 27, 2020 7:11 PM
To: Robert Raszuk ; Zafar Ali (zali) 
Cc: ext-andrew.als...@liquidtelecom.com ; Ron 
Bonica ; spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: Limited domains ...

[External Email. Be cautious of content]


On 28-May-20 10:39, Robert Raszuk wrote:

> Maybe we should just drop right here this "limited domain" restriction/scope 
> for any solution being discussed here ?

In that case we should definitely never have adopted 
draft-ietf-6man-segment-routing-header, whose first reference is RFC8402, which 
is very explicitly a description of a limited doman model:

"Segment Routing domain (SR domain): the set of nodes participating in
 the source-based routing model...   It is expected that all
 nodes in an SR domain are managed by the same administrative entity."

The CRH draft says essentially the same:

"   o  Is designed to operate within a network domain."

Brian



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Ron Bonica]

Zafar,

Many of the drafts that you list below are unrelated to the CRH (e.g., 
draft-bonica-6man-vpn-dest-opt). Many do not exist and are not required (e.g., 
OAM for debugging the mapping table).

Try to understand that the CRH is a building block that can be deployed in many 
scenarios. It is not a grand architecture.

  Ron



Juniper Business Use Only
From: Zafar Ali (zali) 
Sent: Wednesday, May 27, 2020 6:32 PM
To: Brian E Carpenter ; Robert Raszuk 
; ext-andrew.als...@liquidtelecom.com 

Cc: Ron Bonica ; spring@ietf.org; 6man <6...@ietf.org>; 
Zafar Ali (zali) 
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi,

The authors of CRH has already have multiple drafts and more CP/ DP changes 
will be required. E.g., it will require

  *   ISIS changes (draft-bonica-lsr-crh-isis-extensions)
  *   To carry VPN information (draft-bonica-6man-vpn-dest-opt)
  *   For SFC (draft-bonica-6man-seg-end-opt)
  *   BGP changes (draft-alston-spring-crh-bgp-signalling, 
draft-ssangli-idr-bgp-vpn-srv6-plus)
  *   PCEP extension (TBA)
  *   OAM for debugging the mapping table
  *   Yang interface
  *   More to come

The scope of CRH is "limited domain" and not the "Internet".

Given this, where the IETF community discuss how these so-called "building 
blocks" fits together?

If author's claim is that the home for the architecture work is not Spring, 
then the authors should create a BoF in routing area to first defined 
architecture, use-case and requirements.
This is the hard worked everyone else did before the CRH authors.
Why they are looking for a short cut?

CRH is a "major" change and outside the scope of 6man charter.
It should follow the proper IETF review process.

Why CRH authors are trying to "skip the queue" and "skip the routing area"?

Thanks

Regards ... Zafar

From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>>
Date: Wednesday, May 27, 2020 at 6:09 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>>
Cc: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 "spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>, 6man 
<6...@ietf.org<mailto:6...@ietf..org>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On 28-May-20 09:50, Robert Raszuk wrote:
Andrew,

I don't think this is about killing innovation. After all no one is saying you 
can not use it in your network.

WG acceptance calls

Adoption is not acceptance. At least half the messages on this topic are 
written as if we were in the middle of a WG Last Call.

are evaluated in terms of WG rough consensu if significant number of members of 
WG find a proposal useful and if they are willing to work on it.

Indeed. Exactly. Not in the least about consensus that the proposal is ready 
for approval. Just that it is ready for discussion and, as you say, that there 
are people willing to work on it.

It seems clear that other then one vendor and very few individuals majority of 
the WG members do not support the adoption.

That's for the WG Chairs to evaluate, and I expect them to evaluate singing in 
chorus appropriately. Also, and this is not a grammatical quibble, we don't 
have "members". We have participants, and we don't count votes.

I am not against CRH. But what I am against is that CRH/SRm6 authors already 
bounced back via SPRING doors so they have chosen to try to enter via 6man 
window. That is not proper style for any proposal.

I agree that CRH is not in scope of the SPRING charter as it stands today ("the 
home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6)"). But let me 
say again that we should hear the opinion of the routing ADs.

Regards
Brian


IETF IPv6 working group mailing list
i...@ietf.org<mailto:i...@ietf.org>
Administrative Requests: 
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X9nnCHwtlMnfPJCt-JAQWt_RZK_9HziPYxC-DEez6J3r6JBFErtYntrfAskH9yNv$>


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Ron Bonica]

Robert,

If there had never been an SRm6 proposal, would you still object to the CRH?

   
Ron




Juniper Business Use Only
From: Robert Raszuk 
Sent: Wednesday, May 27, 2020 5:50 PM
To: ext-andrew.als...@liquidtelecom.com 
Cc: Ron Bonica ; Zafar Ali (zali) ; 
Henderickx, Wim (Nokia - BE/Antwerp) ; Sander 
Steffann ; spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Andrew,

I don't think this is about killing innovation. After all no one is saying you 
can not use it in your network.

WG acceptance calls are evaluated in terms of WG rough consensu if significant 
number of members of WG find a proposal useful and if they are willing to work 
on it.

It seems clear that other then one vendor and very few individuals majority of 
the WG members do not support the adoption.

I am not against CRH. But what I am against is that CRH/SRm6 authors already 
bounced back via SPRING doors so they have chosen to try to enter via 6man 
window. That is not proper style for any proposal.

Regards,
R.










On Wed, May 27, 2020 at 10:19 PM Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>> 
wrote:
What I find so bizarre is -

You have an multiple operators - who have clearly said - we want this - we see 
advantage of this.  Yet still the obstructionism and denialism continues.  The 
"not invented here" syndrome seems to run deep - and email after email is 
patently ignored from the very people who have to buy the hardware.  Reference 
is made to Montreal - yet the emails that stated the use cases after it went by 
with no response.  No technical objections ever show up - other than - we don't 
want this and you haven't given us this mythical architecture document - which 
was yet another non-technical response that seems so clearly designed to stall 
any innovation that doesn't come from one source.

All I see from the operator perspective here is obstructionism and stalling in 
a desperate attempt to block anything that could be a threat to what was 
dreamed up by someone else.  It is almost as if there is fear that the market 
may choose something other than what was designed - and that fear is driving 
this stance of throw everything we hav against the wall and hope that something 
sticks - because the technical arguments have failed time and again.

This pitbull approach certainly doesn't garner any respect for me, does not 
help to promote srv6 which seems to be what you want and in fact convinces me 
more every day that CRH is the right move - where I can built on top of it 
without the obstructionism of a vendor that seems to have zero interest in what 
mysef and other operators are clearly stating over and over again.

Yet again - I support crh - I've deployed CRH - CRH works for us - and we still 
continue to support it.  And irrespective of if it is adopted - the development 
of it will continue - and it will exist - the only question is - do we end up 
with something that the market wants outside of the auspices of the IETF - or 
do we end up with something that is properly standardized, because this level 
of obstructionism will not prevent the development.

Can we actually get back to proper technical reasoning?

Thanks

Andrew


From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>
Date: Wednesday, 27 May 2020 at 23:07
To: "Zafar Ali (zali)" mailto:z...@cisco.com>>, "Henderickx, 
Wim (Nokia - BE/Antwerp)" 
mailto:wim.henderi...@nokia.com>>, Sander Steffann 
mailto:san...@steffann.nl>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] 
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar,

Why all the passion about stopping the CRH? Does it break any existing 
standard? Does it consume any scarce resource?

You might argue that there is a scarcity of Routing header type numbers. But 
that would be a very short argument. You might argue that WG resources are 
scarce, and that it would take too much time to review this fourteen page 
document. But that argument might take more time than the document review.

In your email, below, you mention "the hardware and software investment from 
vendors". Is that the scarce resource?

Vendors are not obliged to implement every draft that is adopted as a WG item. 
Generally, the marketplace drives product roadmaps.

If the only resource we are protecting is vendor investment, the long-standing 
practice of due diligence should be tempered by operator demand. The IETF 
should

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Ron Bonica]

Zafar,

Why all the passion about stopping the CRH? Does it break any existing 
standard? Does it consume any scarce resource?

You might argue that there is a scarcity of Routing header type numbers. But 
that would be a very short argument. You might argue that WG resources are 
scarce, and that it would take too much time to review this fourteen page 
document. But that argument might take more time than the document review.

In your email, below, you mention "the hardware and software investment from 
vendors". Is that the scarce resource?

Vendors are not obliged to implement every draft that is adopted as a WG item. 
Generally, the marketplace drives product roadmaps.

If the only resource we are protecting is vendor investment, the long-standing 
practice of due diligence should be tempered by operator demand. The IETF 
should not pretend to understand operator requirements better than the 
operators themselves.

Why not let the marketplace decide whether it needs a CRH?


Ron






Juniper Business Use Only
From: Zafar Ali (zali) 
Sent: Wednesday, May 27, 2020 3:19 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) ; Sander 
Steffann 
Cc: Mach Chen ; Ron Bonica ; Chengli 
(Cheng Li) ; 6man <6...@ietf.org>; spring@ietf.org; Zafar Ali 
(zali) 
Subject: Long-standing practice of due-diligence is expected - Re: [spring] CRH 
is not needed - Re: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

WH> My position remains that RFC8663 is a valid alternative and is available; I 
am against WG adoption of CRH.


The industry widely supports RFC8663.



Instead of denying the evidence, could the CRH authors and proponents finally 
understand that people are not opposed to new ideas?



People are reminding a long-standing practice of the IETF process. Before 
tackling a new piece of work, a working group must perform a due diligence on

  1.  whether this new work is redundant with respect to existing IETF 
protocols,
  2.  whether this new work would deliver genuine benefits and use-cases.



It is factually and logically clear to the working-group that the currently 
submitted CRH documents.

  1.  fail to position CRH with respect to existing standard widely supported 
by the industry (e.g., RFC8663)
  2.  fail to isolate new benefit or use-case [1]



This positive collaborative feedback was already given in SPRING.

The CRH authors may change this analysis. They need to document 1 and 2.



Why did the CRH authors not leverage this guidance in SPRING WG?

This was also the chair's guidance in Montreal [2] and Singapore [3]



All the lengthy discussions and debates on the mailing list could be avoided if 
only the CRH authors would tackle 1 and 2.



The CRH authors must tackle 1 and 2.



  *   This is the best way to justify a/the work from the IETF community and b/ 
the hardware and software investment from vendors.
  *   True benefits must be present to justify such a significant engineering 
investment (new data-pane, new control-plane).



Thanks



Regards ... Zafar



[1] 
https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>

[2] 
https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>

[3] 
https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] What's the colour of the hat (was: Re: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH)

[Ron Bonica]

Ole,

No hostility. It was strictly procedural.

I consider you to be a valued friend. In 100 years, nobody will care about any 
of this.

 Ron



Juniper Business Use Only

-Original Message-
From: otr...@employees.org  
Sent: Monday, May 25, 2020 12:41 PM
To: Ron Bonica 
Cc: spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org
Subject: What's the colour of the hat (was: Re: [spring] CRH is back to the 
SPRING Use-Case - Re: Size of CR in CRH)

[snip]

The slight hostility I detect in your replies, I suspect has more to do with 
the particular employer hat I also wear as opposed to the chair hat.

[snip]
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] What's the colour of the hat (was: Re: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH)

[Ron Bonica]

Ole,

OK, the I can reply, contributor to contributor.

Two reasonable people can argue about complexity metrics. Sometimes, these 
arguments make sense.

Sometimes, metrics aren't required. By any measure, my bicycle is a more simple 
machine than my car.

However, I think that it is unfair to say that:

- All discussion of simplicity is marketing
- Any discussion of simplicity visa vis source routing is an oxymoron.


   Ron



Juniper Business Use Only

-Original Message-
From: otr...@employees.org  
Sent: Monday, May 25, 2020 12:41 PM
To: Ron Bonica 
Cc: spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org
Subject: What's the colour of the hat (was: Re: [spring] CRH is back to the 
SPRING Use-Case - Re: Size of CR in CRH)

[External Email. Be cautious of content]


Ron,

[changed subject, as this seems of little relevance]

> So that I will know whether I am allowed to reply.

Wearing a chair's hat has never stopped anyone from replying before.

For formal 6man communication Bob and I generally sign with "Best regards, Bob 
and Ole, 6man co-chairs".
Unless that signature is there you can assume I post as an individual.

>
> Juniper Business Use Only

The slight hostility I detect in your replies, I suspect has more to do with 
the particular employer hat I also wear as opposed to the chair hat.

Ole


> -Original Message-
> From: Ole Troan 
> Sent: Monday, May 25, 2020 12:22 PM
> To: Ron Bonica 
> Cc: Sander Steffann ; Robert Raszuk ; 
> spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org; Ketan Talaulikar 
> (ketant) 
> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in 
> CRH
>
> [External Email. Be cautious of content]
>
>
>> On 25 May 2020, at 17:49, Ron Bonica  wrote:
>>
>> Ole,
>>
>> When commenting on list, could you indicate whether hats are on or off?
>
> And that is important to you for this particular message because?
>
>> Juniper Business Use Only
>
> Ole
>
>> -Original Message-----
>> From: otr...@employees.org 
>> Sent: Monday, May 25, 2020 6:31 AM
>> To: Sander Steffann 
>> Cc: Robert Raszuk ; Ron Bonica ; 
>> spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org; Ketan Talaulikar 
>> (ketant) 
>> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in 
>> CRH
>>
>> [External Email. Be cautious of content]
>>
>>
>> Sander,
>>
>>>> Your below list looks like custom made set of RFP requirements to 
>>>> eliminate any other vendor or any other solution to solve the problem at 
>>>> hand rather then rational list of requirements.
>>>
>>> My main customer (an ISP in NL) would fit exactly in the list that Ron 
>>> sent. They want a simple solution that they can understand and manage, that 
>>> works over IPv6. Whether the path will include many nodes (>8) is not known 
>>> at this point, but they want something that can support it in the future.
>>>
>>> So the list of requirements isn't that strange.
>>
>> That CRH is simple is a bit like claiming that MPLS is simple just because 
>> the header has few fields.
>> I think you would be hard pressed to substantiate that any solution here is 
>> particularly simpler than any other. But you are welcome to try.
>>
>> Everyone claims to want a simple solution, funnily enough the end result is 
>> usually the opposite. The words "simple" and "source routing" are oxymorons.
>> Let's leave the marketing out of this.
>>
>> Ole
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

So that I will know whether I am allowed to reply.

   Ron


Juniper Business Use Only

-Original Message-
From: Ole Troan  
Sent: Monday, May 25, 2020 12:22 PM
To: Ron Bonica 
Cc: Sander Steffann ; Robert Raszuk ; 
spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org; Ketan Talaulikar 
(ketant) 
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]


> On 25 May 2020, at 17:49, Ron Bonica  wrote:
>
> Ole,
>
> When commenting on list, could you indicate whether hats are on or off?

And that is important to you for this particular message because?

> Juniper Business Use Only

Ole

> -Original Message-
> From: otr...@employees.org 
> Sent: Monday, May 25, 2020 6:31 AM
> To: Sander Steffann 
> Cc: Robert Raszuk ; Ron Bonica ; 
> spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org; Ketan Talaulikar 
> (ketant) 
> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in 
> CRH
>
> [External Email. Be cautious of content]
>
>
> Sander,
>
>>> Your below list looks like custom made set of RFP requirements to eliminate 
>>> any other vendor or any other solution to solve the problem at hand rather 
>>> then rational list of requirements.
>>
>> My main customer (an ISP in NL) would fit exactly in the list that Ron sent. 
>> They want a simple solution that they can understand and manage, that works 
>> over IPv6. Whether the path will include many nodes (>8) is not known at 
>> this point, but they want something that can support it in the future.
>>
>> So the list of requirements isn't that strange.
>
> That CRH is simple is a bit like claiming that MPLS is simple just because 
> the header has few fields.
> I think you would be hard pressed to substantiate that any solution here is 
> particularly simpler than any other. But you are welcome to try.
>
> Everyone claims to want a simple solution, funnily enough the end result is 
> usually the opposite. The words "simple" and "source routing" are oxymorons.
> Let's leave the marketing out of this.
>
> Ole
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Ole,

When commenting on list, could you indicate whether hats are on or off?

Ron



Juniper Business Use Only

-Original Message-
From: otr...@employees.org  
Sent: Monday, May 25, 2020 6:31 AM
To: Sander Steffann 
Cc: Robert Raszuk ; Ron Bonica ; 
spring@ietf.org; 6man <6...@ietf.org>; rtg-...@ietf.org; Ketan Talaulikar 
(ketant) 
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]


Sander,

>> Your below list looks like custom made set of RFP requirements to eliminate 
>> any other vendor or any other solution to solve the problem at hand rather 
>> then rational list of requirements.
>
> My main customer (an ISP in NL) would fit exactly in the list that Ron sent. 
> They want a simple solution that they can understand and manage, that works 
> over IPv6. Whether the path will include many nodes (>8) is not known at this 
> point, but they want something that can support it in the future.
>
> So the list of requirements isn't that strange.

That CRH is simple is a bit like claiming that MPLS is simple just because the 
header has few fields.
I think you would be hard pressed to substantiate that any solution here is 
particularly simpler than any other. But you are welcome to try.

Everyone claims to want a simple solution, funnily enough the end result is 
usually the opposite. The words "simple" and "source routing" are oxymorons.
Let's leave the marketing out of this.

Ole

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Ketan,

It would not be fair to say that these operators  "wish to deploy a Traffic 
Engineering solution using a subset of Segment Routing". 

It would be fair to say that these operators  "wish to deploy IPv6 Traffic 
Engineering".  Some of these operators don't care about SR. Some are actively 
averse to SRv6. All they want is a Routing header.

 Ron







Juniper Business Use Only

-Original Message-
From: Ketan Talaulikar (ketant)  
Sent: Monday, May 25, 2020 5:21 AM
To: Ron Bonica ; Joel M. Halpern 
Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]


Hi Ron,

Thanks for that clarification.

I note that you are not anymore saying "Are not interested in SR" like you had 
mentioned before the WG adoption call : 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$

So, would it be fair to say that the operator that you are referring to below, 
wishes to deploy a Traffic Engineering solution using a subset of Segment 
Routing (i.e. a reduced portion of Spring Architecture) that only supports 
prefix and adjacency SIDs as indicated by the two "forwarding methods" that are 
referred to in draft-bonica-6man-comp-rtg-hdr?

Thanks,
Ketan

-Original Message-
From: Ron Bonica 
Sent: 25 May 2020 09:03
To: Ketan Talaulikar (ketant) ; Joel M. Halpern 

Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ketan,

Please consider an operator who:

- Wants a way to steer IPv6 packets through a specified path that includes many 
nodes (>8)
- Does not want any of the following:
- A new VPN encapsulation technique
- A new service function chaining technique
- Network programming
- MPLS and uSID
- To encoding instructions in IPv6 addresses.

These operators want a compact routing header, nothing more.

   Ron


Juniper Business Use Only

-Original Message-
From: ipv6  On Behalf Of Ketan Talaulikar (ketant)
Sent: Sunday, May 24, 2020 1:42 AM
To: Joel M. Halpern 
Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[SNIP]

I am looking for explanation of the "other ways" that CRH can be used (i.e. 
those outside the Spring architecture). I am trying to understand from the 
authors what would be the applicability of that solution, it's use-cases and 
it's requirements. That is what, I believe, will help us evaluate the CRH 
proposal in the context of this working call. That will help us answer these 
questions like the scope of the SID, 32-bit or 16-bit or something else and 
what the CRH-FIB is going to turn out like.


[SNIP]
--
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ron Bonica]

Cheng,

The CRH doesn't attempt the address SFC. That is beyond the scope or a routing 
header.

  Ron


Juniper Business Use Only

-Original Message-
From: Chengli (Cheng Li)  
Sent: Sunday, May 24, 2020 11:44 PM
To: Ron Bonica ; Tom Herbert ; Brian 
E Carpenter 
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]


Hi Ron,

Thank you to share the facts of RFC8200.

Could you please explain how CRH supports SFC by the first Destination Options 
header as you mentioned in you previous email?

Or how to support performing a specific behavior at a specify node along the 
path by using CRH?

You know, when we add an option in the first DOH, it will be processed by all 
the nodes listed in the RH.

Best Regards,
Cheng




-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Monday, May 25, 2020 11:09 AM
To: Tom Herbert ; Brian E Carpenter 

Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] How CRH support SFC/Segment Endpoint option?

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 
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter 
Cc: Robert Raszuk ; Ron Bonica ; 
spring@ietf.org; 6man <6...@ietf.org>
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  
wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk  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

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Ketan,

Please consider an operator who:

- Wants a way to steer IPv6 packets through a specified path that includes many 
nodes (>8)
- Does not want any of the following:
- A new VPN encapsulation technique
- A new service function chaining technique
- Network programming
- MPLS and uSID
- To encoding instructions in IPv6 addresses.

These operators want a compact routing header, nothing more.

   Ron


Juniper Business Use Only

-Original Message-
From: ipv6  On Behalf Of Ketan Talaulikar (ketant)
Sent: Sunday, May 24, 2020 1:42 AM
To: Joel M. Halpern 
Cc: rtg-...@ietf.org; spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[SNIP]

I am looking for explanation of the "other ways" that CRH can be used (i.e. 
those outside the Spring architecture). I am trying to understand from the 
authors what would be the applicability of that solution, it's use-cases and 
it's requirements. That is what, I believe, will help us evaluate the CRH 
proposal in the context of this working call. That will help us answer these 
questions like the scope of the SID, 32-bit or 16-bit or something else and 
what the CRH-FIB is going to turn out like.


[SNIP]
--
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ron Bonica]

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  
Sent: Sunday, May 24, 2020 7:56 PM
To: Brian E Carpenter 
Cc: Robert Raszuk ; Ron Bonica ; 
spring@ietf.org; 6man <6...@ietf.org>
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  
wrote:
>
> On 25-May-20 09:08, Tom Herbert wrote:
> > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk  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.
> >>
&g

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

[Ron Bonica]

Cheng,

IPv6 defines many Routing headers. The Routing header is designed to steer 
packets along a delivery path. Other headers are designed to deliver 
information to nodes along the delivery path.

The Routing header should not attempt to subsume the function of other IPv6 
extension headers.

 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) 
Sent: Sunday, May 24, 2020 1:01 AM
To: Ron Bonica ; 6man <6...@ietf.org>; spring 

Cc: spring 
Subject: Reply: RE: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

Thanks for your reply.

I finally get that CRH only support steering packet along a path.

But I am still curious that how to support a specific function/behavior at the 
specific node by using CRH. Can you please explain that?

Since this is a very basic function we want in the network. SFC needs that, all 
the services needs that if there is any function/service should be performed at 
the middle nodes along the path.

We want to provide an integrated service for our customers, because our 
customers want a integrated solution for providing service, like SFC, VPN, they 
don’t like us to provide a brick that still need to combine with other many 
bricks.

IMHO, when comparing solutions, we should compare the same functionality. So 
could you please provide more info of how CRH supporting services?  It will 
help people to evaluate the CRH, which can help CRH I think.

Thanks,
Cheng







李呈 Cheng Li
Mobile: +86-15116983550
Email: c...@huawei.com<mailto:c...@huawei.com>
From: Ron Bonicamailto:rbon...@juniper.net>>
To: Chengli (Cheng 
Li)mailto:c...@huawei.com>>;6man<6...@ietf.org<mailto:6...@ietf.org>>;springmailto:spring@ietf.org>>
Cc: springmailto:spring@ietf.org>>
Subject: RE: How CRH support SFC/Segment Endpoint option?
Time: 2020-05-24 09:24:55

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




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Saturday, May 23, 2020 12:59 PM
To: Ron Bonica mailto:rbon...@juniper.net>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

Thanks for your reply.

Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation 
between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that 
the NSH packet should visit?

Regarding using the first DOH, how to do that without the container design by 
your draft[1]?
Or the same option TLV will bind to different behaviors on different nodes 
according to the node local configuration?

Best,
Cheng


[1]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) mailto:c...@huawei.com>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn’t attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.


 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org<mailto:6...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org>; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: spring@i

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

[Ron Bonica]

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




Juniper Business Use Only
From: Chengli (Cheng Li) 
Sent: Saturday, May 23, 2020 12:59 PM
To: Ron Bonica ; 6man <6...@ietf.org>; spring@ietf.org
Cc: spring@ietf.org
Subject: RE: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

Thanks for your reply.

Regarding NSH, are you saying to use CRH as a tunnel transport encapsulation 
between two SFF nodes?
Or we can use a single CRH for steering packet through all the SFF nodes that 
the NSH packet should visit?

Regarding using the first DOH, how to do that without the container design by 
your draft[1]?
Or the same option TLV will bind to different behaviors on different nodes 
according to the node local configuration?

Best,
Cheng


[1]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) mailto:c...@huawei.com>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn't attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.


 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org<mailto:6...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org>; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don't really understand how SFC can be supported.


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ron Bonica]

Shuping,

The CRH can appear in a packet along with any valid combination of extension 
headers.

 Ron





Juniper Business Use Only
From: ipv6  On Behalf Of Pengshuping (Peng Shuping)
Sent: Friday, May 22, 2020 11:12 AM
To: Ron Bonica ; Chengli (Cheng Li) 
; 6man <6...@ietf.org>; spring@ietf.org
Cc: spring@ietf.org
Subject: RE: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

If using DOH, then we would have DOH (VPN) + DOH (SFC) + RH per packet in some 
circumstances, right? What if more (ever-emerging) services are required? Not 
sure about the forwarding efficiency.

Best regards,
Shuping


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Friday, May 22, 2020 10:17 PM
To: Chengli (Cheng Li) mailto:c...@huawei.com>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn't attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.


 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) mailto:c...@huawei.com>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org<mailto:6...@ietf.org>>; 
spring@ietf.org<mailto:spring@ietf.org>; Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don't really understand how SFC can be supported.


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ron Bonica]

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified 
path to its destination. It shouldn't attempt to do any more than that.

The CRH does not attempt to deliver service function information to service 
function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service 
function instances.


 Ron




Juniper Business Use Only
From: Chengli (Cheng Li) 
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org>; spring@ietf.org; Ron Bonica 
Cc: spring@ietf.org
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related 
SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this 
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you 
deleted the containers [2].

Without that, I don't really understand how SFC can be supported.


Best,
Cheng



[1]. 
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04..txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Ron Bonica]

Cheng,

Are you assuming that the SPRING charter precludes 6man from ever defining 
another Routing header unless it originates in SPRING?

After all, every IPv6 Routing header facilitates source routing.


Ron




Juniper Business Use Only
From: Chengli (Cheng Li) 
Sent: Thursday, May 21, 2020 12:24 PM
To: Zafar Ali (zali) ; Ron Bonica ; Robert 
Raszuk 
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[External Email. Be cautious of content]

Well, when I read the latest revision, these terms are modified to other words, 
but still feel similar.

Also, I still see the sentence in Introduction:

"
The CRH allows IPv6 source nodes to specify the path that a packet
   takes to its destination.
"

To Ron,

is it a Source Packet Routing paradigm?

If yes, we should start from SPRING WG?

Things are going so fast and I don't understand why a reference deletion can 
made such magic happen?  :(

Best Regards,
Cheng



From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Thursday, May 21, 2020 11:35 PM
To: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Ron,

I sensed that you will propose that ... hence I already asked this question in 
my last email,

Let me repeat. In rev 10 of the CRH document[1], the following SIDs with 
normative reference to SRm6 were defined but removed in Feb. 2020:
"The following are valid segment types:
   o Adjacency.
   o Node.
   o Binding. "

Your proposed text is consistent on how CRH was positioned since inception till 
Feb. 2020, i.e., for SPRING use-case.
However, the very premise of the current adoption call is use-case beyond 
SPRING.
There is a clear need for documenting a genuine use-case & architecture for CRH 
beyond SPRING, before adoption.

[1] 
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10*section-4__;Iw!!NEt6yMaO-gk!QAuA3Dl83zIeqeKCEhswwSXMzW48zN83GY5D6ZiwWA3VkPM6iOFJIwiYIWmNW_1A$>

Thanks

Regards ... Zafar

From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Date: Thursday, May 21, 2020 at 10:19 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: Size of CR in CRH

Robert,

It might makes sense for an operator to:


  *   Allocate identifiers that cause packets to traverse a least-cost path as 
if they had domain-wide significance
  *   Allocate identifiers that cause packets to traverse specific links as 
strictly node local

This concept also exists in SR-MPLS, where prefix SIDs have domain-wide scope 
and adjacency SIDs have node-local scope.

I will make this more clear in the next draft version.

Ron




Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, May 21, 2020 4:34 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: Size of CR in CRH

[External Email. Be cautious of content]

Ron,

> Now recall that identifiers have node local significance.

I was talking about case described in yr draft section 7:


"Applications can:


   o Allocate SIDs so that they have domain-wide significance."

While not a must - it is an option. So I believe my observation stays valid 
till draft either removes that option or describes scaling properties 
differences between both domain wide and local significance of the SIDs.

Thx,
R.


On Thu, May 21, 2020 at 4:01 AM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Robert,

Consider the following network:


  *   Contains 65,000 routers
  *   Each router has 500 directly connected neighbors or fewer
  *   Uses 16-bit CRH

In this network, each node might have 65,499 CRH-FIB entries:


  *   64,999 CRH-FIB entries cause packets to follow the least-cost path to 
another node in the domain
  *   500 CRH-FIB entries cause packets to traverse a specific link to a 
specific neighbor.

As a mnemonic device, an operator might assign identifiers as follows:


  *   0-65,000 identify CRH-FIB entries that cause packets to follow the 
least-cost path to another node in the domain
  *   65,001 - 65,565 identify CRH-FIB entries that that cause packets to 
traverse a specific link to a specific neighbor.

Now recall that identifiers have node local significance. So, Node A and Node B 
might both have a CRH-FIB entry that is identified by the value