Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

A powerful property of RFC8663: No need for kernel access by applications
For example, applications or workloads running in the DC can operate without 
kernel access or need for upgraded IP stacks and still steer traffic over a 
traffic-engineered path (with proven, secure and well known technology).

G/

From: spring  On Behalf Of Henderickx, Wim (Nokia - 
BE/Antwerp)
Sent: Tuesday, May 26, 2020 16:19
To: Mach Chen ; Zafar Ali (zali) 
; Ron Bonica 
; Chengli (Cheng Li) ; 
6man <6...@ietf.org>; spring@ietf.org
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment 
Endpoint option?

I agree that if you look into the details RFC8663 from a data-plane operation 
is very similar to CRH. It uses a tag and derives a destination ipv6 address 
from it.
On top it if you look at the requirements, the following is possible with 
RFC8663


  *   It can steer the packet through a specific path. Implementations exists 
which do well beyond 8
  *   No new VPN encapsulation is required
  *   No new service chaining needed and various options possible.
  *   Compliant to SPRING
  *   Uses MPLS but it is used here as a lookup tag, not any different than the 
CRH proposal. In essence if you look at the details you can implement this with 
a complete v6 infrastructure and use the tag as a steering function. And uses 
32 bit.

As such I don’t see why we need another encap to achieve something we already 
can do and is available in various implementations and is as efficient on the 
wire (looking at 32 bit, which is what people agree upon)

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Mach Chen mailto:mach.c...@huawei.com>>
Date: Tuesday, 26 May 2020 at 11:56
To: "Zafar Ali (zali)" 
mailto:zali=40cisco@dmarc.ietf.org>>, Ron 
Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 "Chengli (Cheng Li)" mailto:c...@huawei.com>>, 6man 
<6...@ietf.org>, 
"spring@ietf.org" 
mailto:spring@ietf.org>>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment 
Endpoint option?

Hi,

If you follow the discussions of the past several months, you should know that 
CRH is the foundation of SRm6. In my understanding, SRm6 is another IPv6 based 
Segment Routing, it was originally motivated to address the SRH header compress 
issue.
Technically, SRm6 works (it has the same concept of SR-MPLS), even if it may 
not support some functions that SRv6 has already supported, it can be extended 
to support them if we want.

But, as many people said, we already have SRv6, SR-MPLS over IP, the community 
has spent so many years of energy and efforts on them, most of the major 
vendors have implemented it, many SPs have deployed and begin to deploy it. 
Given this, do we really want to have another try to define a new solution that 
will provide the same functions as SRv6, SR-MPLS over IP? No doubt, it will 
take years, the same amount of energy and efforts.

Take a step back, assume SRm6 is also adopted, there will be two solutions for 
the community to choose; there will be interop issues between the two 
solutions. The vendors will have to support both to make different customers 
happy, more money will be spent and will be finally payed by the SPs/customers.

Do we really want this?

My two cents.

Best regards,
Mach

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, May 26, 2020 3:02 PM
To: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>;
 Chengli (Cheng Li) mailto:c...@huawei.com>>; 6man 
<6...@ietf.org>; spring@ietf.org
Subject: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi,

It appears that some may have misunderstood the SRv6 solution and invented CRH.
It is good to clarify these points.

SRv6 offers the possibility to combine underlay and overlay instructions in a 
single SRH.
However,

  *   This is entirely optional
  *   If one would like to spread the source routed policy between multiple 
extension headers, one can use SRv6 to do this

 *   SRH to hold the topological endpoints
 *   Any combination of other extension headers to hold VPN and/or Service 
information. For example, SRH works seamlessly with NSH as documented in a WG 
document https://tools.ietf.org/html/draft-ietf-spring-nsh-sr-02.

Claiming that a new data plane is needed to achieve this separation is false.

Claiming that CRH is needed to decrease the overhead of source-routed policy in 
IPv6 is incorrect, too. Many members of the SPRING working group have produced 
documents to extend the SRv6 solution for the specific purpose of minimizing 
the MTU overhead and/or supporting very long SID-lists on legacy hardware.

Also, CRH is just a re-engineering of SR-MPLS Data Plane with IPv6 Control 
Plane [RFC8663] and RFC8663 is an already productized, deployed, proven, and 
standardized solution.

6man took 6 years to define SRH. The 6man WG spent a lot of 

Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are 
signaled for ISIS, OSPF and BGP-LS. 

If the WG's can manage to agree upon a decision (option1/2/3 or 4), then next, 
have a look into how to encode the TLV so that we have a clean technological 
solution space.

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 10:45
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

In that case, I concur with you that option (2) is better than the others. My 
only difference in opinion is that ERLD not have its own separate TLV but 
instead get advertised as a new MSD sub-type - it is just a different encoding.

Thanks,
Ketan

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)  
Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; i...@ietf.org; l...@ietf.org; 
spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding seems to make little sense and only bring confusion 
>(router/controller implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion)
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2))
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators
* most simple solution for implementers (routers and controller)
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readab

Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding 
seems to make little sense and only bring confusion (router/controller 
implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion) 
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2)) 
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators 
* most simple solution for implementers (routers and controller)  
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mail

Re: [spring] draft-xu-mpls-sr-over-ip

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi Loa,

I am not aware of any IPR related to this draft.

Best regards,
Gunter Van de Velde

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Loa Andersson
Sent: Thursday, June 7, 2018 12:15
To: m...@ietf.org
Cc: spring@ietf.org; mpls-cha...@ietf.org; draft-xu-mpls-sr-over...@ietf.org
Subject: [spring] draft-xu-mpls-sr-over-ip

Working Group,

We are currently preparing draft draft-xu-mpls-sr-over-ip for working group 
adoption.

Part of this preparation is to do an IPR poll.

This mail is to start the IPR poll.

Are you aware of any IPR that applies to draft-xu-mpls-sr-over-ip?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures against draft-xu-mpls-sr-over-ip.

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the MPLS WG mailing list.* The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the MPLS WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

We have copied this mail to the SPRING wg mailing list for information.
If you receive this mail over the SPRING wg mailing list, and are aware of IPRs 
that apply to the draft, please notify the MPLS wg list.


/Loa
  mpls wg co-chair
-- 


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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

[spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth)
ISIS/OSPF is signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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

Re: [spring] [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Mark,

Yeah... you may be right... we added the intro part to start the draft because 
mentioning the construction "using Flow-Label" seems to have toxic email storm 
effect on email lists around v6. Hence the disclaimers on flow-label usage at 
the start of the text. Maybe it is wrongly placed and gives the wrong 
impression indeed... it is for sure not the intent... It is our intent to set 
flow-label on the outer tunnel header, and this is done by the router which is 
imposing the IPv6 tunnel outer header, but we are not fiddling on the fly with 
transit flow-labels at all. This seems not to break any IPv6 rules I think.

However, as you point out the case of SRv6 EH insert, is a different story and 
requires a bit more thought. It is possible also, but needs to use the SRv6 
Opaque value-containers to carry the original Flow-label across the domain to 
reconstruct the original flow-label value. Nevertheless, RFC8200 seems rather 
restrictive on EH insertion, and hence we conveniently assumed that chances are 
low for it to become reality due to IPv6 specification complexities and we 
disregarded EH inject.

G/


-Original Message-
From: Mark Smith [mailto:markzzzsm...@gmail.com] 
Sent: Tuesday, November 7, 2017 09:04
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>
Cc: v6...@ietf.org; spring@ietf.org
Subject: Re: [v6ops] FW: New Version Notification for 
draft-fioccola-spring-flow-label-alt-mark-01.txt

Hi Gunter,

On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp) 
<gunter.van_de_ve...@nokia.com> wrote:
> Hi Mark,
>
> The flow label of the original packet is untouched. It is never manipulated 
> in this proposal. The flow label that is set in this proposal is done at the 
> SRv6 tunnel-head end which imposes the SRv6 encapsulation header. It is this 
> encapsulation header which has the flow label which is used in this draft.
> So basically, it is just the SRv6 tunnel outer encap header which is used for 
> alternate packet marking. And this is set only one time by the original SRv6 
> tunnel head-end router (which is the source address of the IPv6 SRv6 
> tunnel...). This outer SRv6 header is removed when the packet exits the SRv6 
> domain, and the original flow label appears again untouched. This does not 
> break any RFC at all because all because the original flow-label of the 
> original IPv6 packet is never touched.
>
> So, in this proposal there is no device which is changing flow-labels at all. 
> It is only during the imposing of the SRv6 outer header, that the flow label 
> field is set once for Alternate marking purposes inside the outer SRv6 tunnel 
> header.
>
> Hope it clarifies?
>

It does, although it seems to be contrary to quite a lot of the introduction 
text:


"The flow label is an immutable field recommended to contain a pseudo-
   random value [RFC6437].  However, in most packets it has the default
   value of zero, although some TCP/IP stacks do set it according to
   [RFC6437].

   [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used
   in controlled environment,..."

"Based on these considerations, it is allowed to use the flow label
   field in a managed domain, assuming when a packet leaves the domain,
   the original flow label value MUST be restored."

and the later reference to
"[I-D.voyer-6man-extension-header-insertion]" all seems to be setting up a case 
to justify modifying the original packet's flow label value and then restoring 
it using the original value that has been somehow sent or signalled to the 
network egress.

As you've said, when tunnelling, the original packet and its flow label value 
is entirely preserved, so there doesn't need to be any of the above text. Even 
the text about hosts not setting the FL value isn't really necessary, as tunnel 
end-points, as a function at the
IPv6 layer, are hosts that originate packets, so they can set the FL value to 
what ever they like because they're originating the (tunnel) packet.


I think it might be better to avoid using two of the FL bits to encode the 
marking method, as that also deviates from RFC6437 (I seem to remember we also 
thought about using some bits in the FL to encode something during that time, 
and also abandoned it.)

I'm not across the Alternate Marking Method work, so this might be a dumb 
question or suggestion. Within a measurement domain, is there ever going to be 
a mix of single and double marking, such that it needs to be encoded 
per-packet? If a domain can only support one of them at any one time, then I 
think that could be encoded in the configuration of the SRv6 tunnel end points, 
rather than encoding it in a couple of the FL bits.

Also, there is now an IPv6 Performance and Diagnostics Destination Option which 
may be a IPv6 conventional way of encoding this marking or measurement 
info