Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Francois Clad (fclad)]

Hello Erik,

You may find some examples here: 
https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/

Hope this helps.

Thanks,
Francois

From: spring  on behalf of Erik Kline 

Date: Thursday, 14 October 2021 at 19:06
To: Joel M. Halpern 
Cc: spring@ietf.org , i...@ietf.org 
Subject: Re: [spring] Question from SPRING regarding 
draft-filsfilscheng-spring-srv6-srh-compression
Joel,

Thank you for your email.  The ADs and chairs have been discussing.

One thing that would be very helpful to our discussions would be some worked 
examples of the various C-SID behaviors, showing some SRv6 datagrams and what 
happens to their contents as they move across some suitable example SR domain.

(It would also be helpful if they showed what happens to something like an 
ICMPv6 Echo Request to a representative Destination Address in these cases 
when, say, an SRH is not present, i.e. to see when typical unicast semantics 
are preserved or when something more like anycast or multicast behavior is to 
be expected.)

Assuming some forthcoming helpful examples, we have a goal to get a more 
complete answer back to you by the latter half of next week.

Thanks,
-Erik

On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern 
mailto:j...@joelhalpern.com>> wrote:
The SPRING working group is in the midst of an adoption call on
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.

The SPRING charter has text that is explicit that modifications to data
planes and architectures standardized by other working groups may not be
modified in SPRING unless the chairs and ADs responsible for that data
plane and / or architecture agree.

To complete the context, as my SPRING co-chairs are co-authors on the
document in question, they have recused themselves from decisional
activities regarding the document.  Therefore, this message is coming
just from my as the responsible SPRING co-chair managing this adoption call.

As you have seen, multiple questions have been raised about the
relationship of the document to the IPv6 defined data plane and
architecture (particularly RFC 4291 and 8200). In particular the
questions seem to revolve around what the document describes as the
NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
standards.  (For those seeking more context without reading the full
document, a paraphrase and simplification of the NEXT-C_SID flavor is
provided as a postscript.)

I raised the question of concurrence as required by the SPRING charter
with the Internet ADs and SPRING chairs.  They quite reasonably asked me
to write a note to 6man explaining the concerns as clearly as a can, so
that they can then determine how to proceed.

The questions that prompted my inquiry are:

1) Does the placement of a list of sids in the IPv6 DA field change the
IPv6 architectural description of that field.
2) Does the operation of shifting information around in the IPv6
destination address field represent a modification or extension of the
IPv6 data plane.

On a related note, the document in question also defines two other
flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
flavor operation, so seems to be affected by the same question.

 From my own reading, it appears that the REPLACE-C-SID flavor does not
raise issues requiring 6man leadership concurrence.

Yours,
Joel M. Halpern for the SPRING working group


PS:
Clearly, understanding the question requires some understanding of what
the NEXT-C_SID flavor does.   This explanation is a simplification for
length and context.  Really, the best place to understand it is the
draft.  However, to give you enough information to let you decide
whether you care, I will try to provide a fair summary.  My apologies in
advance to the authors for necessary liberties for length.  Also,
discussion of the draft contents (as distinct from the interaction with
the IPv6 data plane and architecture) belongs on the SPRING list, and
should not clutter up 6man.

SIDs are the identifiers used in segment routing.
In SRv6, as document in the current RFCs, these are 128 bits.   As
defined in the relevant RFCs, SIDs which identify endpoints to which
packets are directed are identified by endpoint SIDs.  These can have
behaviors (decapsulate and forward is one example).  They can have
flavors such as where the SRH is removed.

The topic under discussion is means to compress these SIDs in the
packets on the wire.  The document under discussion provides three
flavors of compression.

The fundamental mechanism of the draft is to use a single SRH entry as a
container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is
first encountered the entire container is copied into the desination
address of the IPv6 packet.  The container has a common routing prefix
used for all the NEXT-C-SID SIDs.  It is followed by a sequence of
compressed SIDs of a configured length.  One could 

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

[Francois Clad (fclad)]

Hi Greg,

Your understanding is correct. The C-SID flavors cannot be randomly mixed 
within the same C-SID container.

We can clarify the details related to the combination of flavors in a C-SID 
container in an upcoming version of the draft. For example, the last entry of a 
C-SID container can carry a C-SID bound to any behavior, including one with 
another C-SID flavor.

Thanks,
Francois

From: Greg Mirsky 
Date: Friday, 8 October 2021 at 22:21
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, 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/
Hi Francois,
you've said that different flavors of C-SID can be present not only in the same 
SRH but also in the same C-SID container. The latter case got me thinking about 
several potential scenarios. Have to admit that I got stuck trying to 
understand how they can work. I hope you can help me out. Please consider the 
two cases described below.

Consider, for all cases, that we are handling a container with entries A, B, C, 
and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors.

Case 1:
Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID 
flavor. When A is processed, B will be copied into the IPv6 DA, retaining the 
prefix before A in the container. So far, so good. Then, when the packet 
arrives at the node that processes B, it will say "NEXT". The remaining bits 
will be? I thought zero, but actually, it will presumably be two bits with the 
value two? So the subsequent behavior will shift that two up? Even if the 
NEXT-C-SID flavor guesses that the two should be zero, it would skip C and D 
and pick up the entry from the next C-SID container in the SRH. So it seems to 
either work wrong or work oddly?

Case 2:
Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwards 
in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret the 
upper bits of the C C-SID as the arg for selecting the position in the C-SID 
container to pull an entry from. It will also modify the C C-SID to perform the 
decrement it thinks it needs. It will then overwrite itself with the randomly 
chosen entry from the container.

It seems that neither scenario works. At least, I cannot figure out how it can 
work. I would greatly appreciate it if you could have a look and clarify it for 
me.
Regards,
Greg

On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) 
mailto:fc...@cisco.com>> wrote:
Hi Greg,

Thank you for the confirmation. I am glad that the matter of combining C-SIDs 
of different flavors is clear now.

Thanks,
Francois

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Thursday, 7 October 2021 at 20:15
To: Francois Clad (fclad) mailto:fc...@cisco.com>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto: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/
Hi Francois,
thank you for your detailed response and confirming that C-SIDs of different 
flavors/behavior may be present in the same SRH and even the same CSID 
container. I've noticed Ron's proposal as I was trying to formulate my 
question. His proposal highlighted what I am trying to understand - the 
relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG 
has adopted the compression analysis 
draft<https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/>,
 and the updates and an additional analysis Ron proposed will keep the 
discussion and decision-making process on the firm technical foundation.

Regards,
Greg

On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) 
mailto:fc...@cisco.com>> wrote:
Hi Greg,

It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the 
segment list in the SRH. It learns about the available SIDs in the network with 
their associated behavior and flavors via control plane and/or management plane 
protocols, as described in Section 8 of RFC 8986, and selects the SIDs that are 
the most appropriate for the segment list.

Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the 
pseudocode of a locally instantiated SID when it receives a packet matching 
that SID. The SR Segment Endpoint Node does not need to bother about the 
behavior/flavor of the subsequent SRv6 SIDs.

This SRv6 logic applies to the C-SID flavors as well. The choice of flavors for 
the SIDs in the SID List is up to the SR Source Node.

It is indeed possible to mix SIDs of different C-SID flavors in the same SRH, 
and even in a single C-SID container.

Thanks,
Francois


From

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

[Francois Clad (fclad)]

Hi Tarek,

Section 4.3 of RFC 8754 indicates that a locally instantiated SID is identified 
based on the result of an LPM lookup on the packet’s destination address. That 
SID has a behavior that determines how the endpoint node should process the 
packet.

The C-SID draft does not change how the endpoint node identifies a SID.

Could you provide an example showing the kind of inference or collision you are 
referring to?

Thanks,
Francois

From: Tarek Saad 
Date: Sunday, 10 October 2021 at 06:06
To: Francois Clad (fclad) , 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/
Hi Francois,

Thanks for your responses. Please see inline..

From: Francois Clad (fclad) 
Date: Friday, October 8, 2021 at 1:14 PM
To: Tarek Saad , 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/
Hi Tarek,

I am assuming that the border node is an SR segment endpoint node in your 
question.
[TS]: yes.

This node processes the packet according to the behavior bound to the locally 
instantiated SID that was matched (see Section 4.3 of RFC 8754). There is no 
interpretation required.
[TS]: consider the case that two locally instantiated SIDs (carried in the DA) 
can match – like SID1 is contained within SID2 (or vice versa). Absence 
anything present in the encoded SID-sequence, how can this node reliably infer 
whether it is G-SID sequence or a C-CSID sequence?

It is the responsibility of the SR source to make sure that the SIDs in the 
Segment-List are used appropriately. This applies to all SRv6 SIDs, including 
those defined in RFC 8986. It is the same as ensuring that there is not an 
End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the 
right interface is used.
[TS]: I’m not sure it is solely a SR source responsibility. There is some 
responsibility that the node allocated the 2 kinds of SIDs that need to ensure 
no such previous collision can ever occur, no?

Regards,
Tarek

Thanks,
Francois

From: spring  on behalf of Tarek Saad 

Date: Friday, 8 October 2021 at 06:06
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/
Hi all,

I’ve read this draft. It is proposing 2 different encodings schemes for 
compressed sequence of SRv6 SIDs (and an optional behavior on border nodes)..
Although Section 4 makes a claim that different deployments usecase may deem 
one encoding scheme superior over the other, I could not glean in which cases a 
scheme would outperform the other and why? Or, why is the WG trying to 
standardize both the two flavors -- keeping in mind the complex HW procedures 
evident by the proposed different pseudo codes in the draft.

Also, are there concerns of misinterpreting (wrongfully decoding) a GSID 
sequence for a C-SID-sequence (or vice-versa) for a received packet on border 
nodes that may support both encoding flavors simultaneously?

For these reasons, I think this it is still premature for this draft to be 
adopted, and I oppose its adoption.

Regards,
Tarek


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 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/
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

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

[Francois Clad (fclad)]

Hi Gyan,

Thanks for your feedback. The authors will work on some more illustrations to 
add in the draft.

In my previous email 
(https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2L8/), I 
provided an example of how the Next-C-SID and Replace-C-SID flavors could be 
used together and with different C-SID lengths. Let me restate that, as shown 
in this example, there is no least common denominator for C-SID lengths between 
the flavors.

As a side note, could you please use the terminology defined in this C-SID 
draft or in RFC 8986/8754? Your emails seem to mix them up and makes it 
difficult for me to understand your questions.

Thanks,
Francois

From: Gyan Mishra 
Date: Sunday, 10 October 2021 at 22:23
To: Chengli (Cheng Li) , Francois Clad (fclad) 

Cc: James Guichard , SPRING WG 
, Yisong Liu , spring-chairs 

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

Hi Francois, Chengli & authors

Many Thanks for your feedback to the WG on the critical topic interoperability 
of the uSID micro-sid 16 bit uSID   “NF=Locator/Function combo”  128 bit 
container based solution and the G-SRV6 32 bit G-SID “NF=Locator/Function 
combo” 4 - 32 bit G-SID in 128 bit container based solution defined as Next and 
Replace flavors in the draft.

I am really concerned as to how the next and replace interoperability would 
work for adjacent nodes using SID within same or adjacent container.

Section 6.1 mentions that  Next flavor recommendation is for 16 bit as the uSID 
draft & this draft NF as 16 bit is most optimal uSID size within the uSID 
container and Replace flavor recommendation is for 16 bit as the G-SRV6 draft & 
this draft NF as 32 bit G-SID is most optimal G-SID size within the G-SID 
container.

Please  elaborate on this in more detail, as with this draft for next and 
replace interoperability, following the SRv6 compression requirements for 
optimal hardware forwarding and state efficiency that Next would be recommended 
to use 16 bit SID and Replace would be recommended 32 bit SID.   Please 
elaborate in detail as to why 16 bit is not recommended for replace flavor and 
32 bit is not recommended for next flavor for all of the requirements drafts 
list of SRv6 compression requirements each one by one and the problems 
encountered when not using the recommended SID length.

Thus for next and replace flavor interoperability even possible  to work would 
require two different SID sizes within the same container interoperability 
caveats and now you have to deal with uSID container style using 16 bit SID and 
G-SID container style using 32 bit SID.

From the requirements draft,  interoperability perspective, the primary 
objective is “encapsulation header compression” as that is what we have spent 
over a year on with DT finding an optimal compression solution.  So here the 
lowest common denominator ends up being 32 bit SID and we now have failed the 
primary objective of a compression solution.

As far as lowest common denominator is it true that in order to meet all the 
requirements draft list of all SRv6 compression requirements both next and 
replace have to revert to that lowest common denominator which is 32 bit SID.  
If that is true, unfortunately that makes the draft fail the primary objective 
of any SRv6 compression solution.

To that end as far as interoperability on Next and Replace interoperability 
being the hinge pin of this drafts adoption, as well even if the authors state 
that Replace can use 16 bit SID as a possibility, as the 32 bit “NF” G-SID is 
recommended for hardware forwarding efficiency and scalability that if 16 bit 
were used G-SID would fail the hardware forwarding efficiency and scalability 
requirements as well as possibly other requirements which should also be stated 
in the draft.


6.1<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-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.

The draft should mention the recommendation for common block length for 
interoperability.  The only block size possible is 48 bit so block size so that 
would be a major addressing inflexibility for interoperability.


6.2<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-6.2>.
  Block Length



   The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are

   16, 32 or 48 bits.  The smaller the block, the higher the compression

   efficiency.



   The recommended SRv6 SID block size for the REPLACE-C-SID flavor can

   be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator.


Taking this further another step as this draft needs to describe 

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

[Francois Clad (fclad)]

Hi Gyan,

It is possible to combine SIDs of different C-SID flavors and C-SID lengths in 
the same SRH, along with those defined in RFC 8986 After all, they leverage the 
same SRv6 data plane.

Let me give you an example.

Assume that an SR source node wants to send a packet onto an SR path through 10 
SR segment endpoint nodes (nodes 1 through 10), and have a VPN termination for 
a VRF 123 on a last SR segment endpoint node 11.

The SR source node selects the segments as follows:

  *   On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the node 
ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length.
  *   On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being the 
node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length.
  *   On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986).
  *   On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for 
VRF 123.

The SR source node then sends the packet onto the SR path by performing the 
H.Encaps.Red behavior with:

  *   IPv6 Source Address = 
  *   IPv6 Destination Address = 2001:db8:0:0101:0201:0301:0401:0501
  *   SRH =
 *   SegmentList[0] = 2001:db8:0:1100:d123::
 *   SegmentList[1] = 1000:0001:0900:0001:0800:0001:0700:0001
 *   SegmentList[2] = 2001:db8:0:0600:0001::

Therefore, there is no notion of lowest common denominator for C-SID length. 
Based on the deployment requirements, an operator has the flexibility to select 
the SRv6 SID flavor and C-SID lengths of their choice.

We can update the draft with this type of illustrations.

Thanks,
Francois

From: spring  on behalf of Gyan Mishra 

Date: Sunday, 3 October 2021 at 21:01
To: Yisong Liu 
Cc: James Guichard , SPRING WG 
, spring-chairs 
Subject: Re: [spring] RE： WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi Yisong

The main goal for operators is interoperability.  As interoperability is the 
key reason for a single SRv6 compression solution that we have WG consensus and 
is desired.

Continued details of the interoperability study  should be added to the draft 
as the study progresses.

One key detail that is missing is forwarding efficiency and scalability using 
NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID.

As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra 
scale  SRv6 compression solution is recommended for 16 bit SID and 
REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit 
SID.

Of all the requirements as stated, the encapsulation header size is the primary 
objective for operators to eliminate MSD issues with optimal forwarding and 
state efficiencies.

At this time in order for Next and Replace solutions to be interoperable 
keeping in mind requirements for optimal forwarding and state efficiency 32 bit 
SID would be the lowest common denominator which should be stated as the 
baseline result of the analysis draft on CSID overall 2 prong solution.

CSID draft:
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-11

Bottom of section 11:


   The interoperability was validated for the following scenario:



   o  Packet forwarding through a traffic engineering segment list

  combining, in the same SRH 
([RFC8754]), SRv6 SIDs bound to 
an

  endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound

  to an endpoint behavior with the REPLACE-C-SID flavor.



   Further interoperability testing is ongoing and will be reported in

   this document as the work progresses.

King Regards

Gyan
On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu 
mailto:liuyis...@chinamobile.com>> wrote:
Hi Chairs & WG,

I strongly support the adoption call. Regarding chair's note in the email, I 
would like to point that the network programming model (RFC8996) by nature 
defines multiple behaviors. CSID has a single SRv6 based data plane that 
defines the next and replace behaviors consistent with the network programming 
paradigm.

CSID's next and replace behaviors have been verified by interoperability test 
in China mobile laboratory and there is no problem with the interworking of the 
two behaviors on the CSID dataplane.

Best Regards
Yisong

发件人: James Guichard
时间: 2021/10/01(星期五)22:04
收件人: SPRING WG;
抄送人: spring-chairs;
主题: [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 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as 

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

[Francois Clad (fclad)]

Hi Tarek,

I am assuming that the border node is an SR segment endpoint node in your 
question.

This node processes the packet according to the behavior bound to the locally 
instantiated SID that was matched (see Section 4.3 of RFC 8754). There is no 
interpretation required.

It is the responsibility of the SR source to make sure that the SIDs in the 
Segment-List are used appropriately. This applies to all SRv6 SIDs, including 
those defined in RFC 8986. It is the same as ensuring that there is not an 
End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the 
right interface is used.

Thanks,
Francois

From: spring  on behalf of Tarek Saad 

Date: Friday, 8 October 2021 at 06:06
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/
Hi all,

I’ve read this draft. It is proposing 2 different encodings schemes for 
compressed sequence of SRv6 SIDs (and an optional behavior on border nodes)..
Although Section 4 makes a claim that different deployments usecase may deem 
one encoding scheme superior over the other, I could not glean in which cases a 
scheme would outperform the other and why? Or, why is the WG trying to 
standardize both the two flavors -- keeping in mind the complex HW procedures 
evident by the proposed different pseudo codes in the draft.

Also, are there concerns of misinterpreting (wrongfully decoding) a GSID 
sequence for a C-SID-sequence (or vice-versa) for a received packet on border 
nodes that may support both encoding flavors simultaneously?

For these reasons, I think this it is still premature for this draft to be 
adopted, and I oppose its adoption.

Regards,
Tarek


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 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/
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] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Francois Clad (fclad)]

Hi Greg,

Thank you for the confirmation. I am glad that the matter of combining C-SIDs 
of different flavors is clear now.

Thanks,
Francois

From: Greg Mirsky 
Date: Thursday, 7 October 2021 at 20:15
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, 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/
Hi Francois,
thank you for your detailed response and confirming that C-SIDs of different 
flavors/behavior may be present in the same SRH and even the same CSID 
container. I've noticed Ron's proposal as I was trying to formulate my 
question. His proposal highlighted what I am trying to understand - the 
relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG 
has adopted the compression analysis 
draft<https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/>,
 and the updates and an additional analysis Ron proposed will keep the 
discussion and decision-making process on the firm technical foundation.

Regards,
Greg

On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) 
mailto:fc...@cisco.com>> wrote:
Hi Greg,

It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the 
segment list in the SRH. It learns about the available SIDs in the network with 
their associated behavior and flavors via control plane and/or management plane 
protocols, as described in Section 8 of RFC 8986, and selects the SIDs that are 
the most appropriate for the segment list.

Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the 
pseudocode of a locally instantiated SID when it receives a packet matching 
that SID. The SR Segment Endpoint Node does not need to bother about the 
behavior/flavor of the subsequent SRv6 SIDs.

This SRv6 logic applies to the C-SID flavors as well. The choice of flavors for 
the SIDs in the SID List is up to the SR Source Node.

It is indeed possible to mix SIDs of different C-SID flavors in the same SRH, 
and even in a single C-SID container.

Thanks,
Francois


From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) mailto:fc...@cisco.com>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto: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/
Hi Francois,
thank you for the clarification. It is still not clear how a node selects which 
flavor of CSID to use on the next compressed CSID that may happen also be in 
the next CSID container. As I understand it, a CSID container must use the same 
flavor of compression but CSID containers with different compression flavors in 
the same SRH are allowed. Is that correct understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) 
mailto:fc...@cisco.com>> wrote:
Hi Greg,

A node that supports this draft in its entirety can instantiate SRv6 SIDs 
(e.g., End and End.X SIDs) with any of the three C-SID flavors.

In particular, a node can instantiate multiple SRv6 SIDs bound to different 
C-SID flavors, possibly with different C-SID lengths. It can also instantiate 
SRv6 SIDs with behaviors and flavors defined in RFC 8986.

As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, upon 
receiving an IPv6 packet with a destination address matching a FIB entry that 
represents one of these locally instantiated SIDs, the node processes the 
packet according to the behavior (and flavor(s)) (i.e. pseudocode) of that SID.

RFC 8754 and 8986 have already standardized these mechanisms and the C-SID 
draft only leverages the same SRv6 dataplane to introduce new endpoint flavors 
for compression.


Francois

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto: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/
Hi Robert,
as I understand it, you believe everything that is written in the draft. I hope 
you can help me find an answer to one simple question:
Can a node that supports this draft in its entirety, i.e., supports all 
"flavors" defined in the document, process received SRv6 packet with the SRH 

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

[Francois Clad (fclad)]

Hi Greg,

It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the 
segment list in the SRH. It learns about the available SIDs in the network with 
their associated behavior and flavors via control plane and/or management plane 
protocols, as described in Section 8 of RFC 8986, and selects the SIDs that are 
the most appropriate for the segment list.

Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the 
pseudocode of a locally instantiated SID when it receives a packet matching 
that SID. The SR Segment Endpoint Node does not need to bother about the 
behavior/flavor of the subsequent SRv6 SIDs.

This SRv6 logic applies to the C-SID flavors as well. The choice of flavors for 
the SIDs in the SID List is up to the SR Source Node.

It is indeed possible to mix SIDs of different C-SID flavors in the same SRH, 
and even in a single C-SID container.

Thanks,
Francois


From: Greg Mirsky 
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, 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/
Hi Francois,
thank you for the clarification. It is still not clear how a node selects which 
flavor of CSID to use on the next compressed CSID that may happen also be in 
the next CSID container. As I understand it, a CSID container must use the same 
flavor of compression but CSID containers with different compression flavors in 
the same SRH are allowed. Is that correct understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) 
mailto:fc...@cisco.com>> wrote:
Hi Greg,

A node that supports this draft in its entirety can instantiate SRv6 SIDs 
(e.g., End and End.X SIDs) with any of the three C-SID flavors.

In particular, a node can instantiate multiple SRv6 SIDs bound to different 
C-SID flavors, possibly with different C-SID lengths. It can also instantiate 
SRv6 SIDs with behaviors and flavors defined in RFC 8986.

As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, upon 
receiving an IPv6 packet with a destination address matching a FIB entry that 
represents one of these locally instantiated SIDs, the node processes the 
packet according to the behavior (and flavor(s)) (i.e. pseudocode) of that SID.

RFC 8754 and 8986 have already standardized these mechanisms and the C-SID 
draft only leverages the same SRv6 dataplane to introduce new endpoint flavors 
for compression.


Francois

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto: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/
Hi Robert,
as I understand it, you believe everything that is written in the draft. I hope 
you can help me find an answer to one simple question:
Can a node that supports this draft in its entirety, i.e., supports all 
"flavors" defined in the document, process received SRv6 packet with the SRH 
encoded according to the specification?
So far, the proponents of the draft referred to "planning" how flavors of SRv6 
SID compressed. To the best of my understanding, that is is a clear 
demonstration of the incompatibility between flavors defined in the CSID draft. 
Regardless of what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk 
mailto:rob...@raszuk.net>> 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 i

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

[Francois Clad (fclad)]

Hi Greg,

A node that supports this draft in its entirety can instantiate SRv6 SIDs 
(e.g., End and End.X SIDs) with any of the three C-SID flavors.

In particular, a node can instantiate multiple SRv6 SIDs bound to different 
C-SID flavors, possibly with different C-SID lengths. It can also instantiate 
SRv6 SIDs with behaviors and flavors defined in RFC 8986.

As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, upon 
receiving an IPv6 packet with a destination address matching a FIB entry that 
represents one of these locally instantiated SIDs, the node processes the 
packet according to the behavior (and flavor(s)) (i.e. pseudocode) of that SID.

RFC 8754 and 8986 have already standardized these mechanisms and the C-SID 
draft only leverages the same SRv6 dataplane to introduce new endpoint flavors 
for compression.


Francois

From: spring  on behalf of Greg Mirsky 

Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk 
Cc: Ron Bonica , 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/
Hi Robert,
as I understand it, you believe everything that is written in the draft. I hope 
you can help me find an answer to one simple question:
Can a node that supports this draft in its entirety, i.e., supports all 
"flavors" defined in the document, process received SRv6 packet with the SRH 
encoded according to the specification?
So far, the proponents of the draft referred to "planning" how flavors of SRv6 
SID compressed. To the best of my understanding, that is is a clear 
demonstration of the incompatibility between flavors defined in the CSID draft. 
Regardless of what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk 
mailto:rob...@raszuk.net>> 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/ ).


 Ron
___
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/

[Francois Clad (fclad)]

I support the working group adoption.

The C-SID solution described in this I-D builds on the SRv6 data plane defined 
in RFC 8754 and 8986 to provide a flexible, SRv6-native compression solution. 
It has been implemented by several vendors, with interoperability testing 
reported in section 11.

Furthermore, the SRComp design team analysis demonstrated that this solution 
meets all the compression requirements and provides the best data plane 
efficiency among all the evaluated solutions.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Friday, 1 October 2021 at 16:05
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/
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] IPR Call for draft-ietf-spring-segment-routing-policy

[Francois Clad (fclad)]

Hi Jim, chairs,

I am not aware of any undisclosed IPR related to this document.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Sunday, 11 April 2021 at 12:34
To: SPRING WG 
Cc: spring-cha...@ietf.org 
Subject: [spring] IPR Call for draft-ietf-spring-segment-routing-policy
Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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

Re: [spring] SRv6 Service Programming using TLV

[Francois Clad (fclad)]

Hi Luc-Fabrice,

This demo is an illustration of the Segment Routing Service Programming 
capabilities defined in draft-ietf-spring-sr-service-programming 
(https://datatracker.ietf.org/doc/draft-ietf-spring-sr-service-programming/). 
In this demo, the metadata was first carried as a SID argument, and then 
transcribed into an SRH TLV.

Please let me know if you have any specific question about this I-D, or feel 
free to contact me privately for more information about the demo.

Regards,
Francois

From: spring  on behalf of Pengshuping (Peng Shuping) 

Date: Wednesday, 31 March 2021 at 09:01
To: Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ] , 
a...@ietf.org 
Cc: 'spring@ietf.org' 
Subject: Re: [spring] SRv6 Service Programming using TLV
Hi Fabrice,

An interesting demo! APN could refer to this way to do with the SRv6 SFC. Thank 
you!

Maybe folks @SPRING WG would know more about it, so I copied the SPRING WG. 
Anybody would like to help here?

https://www.youtube.com/watch?v=NCZzhdu1OCE

Thanks!

Best Regards,
Shuping



From: Apn [mailto:apn-boun...@ietf.org] On Behalf Of Luc-Fabrice Ndifor Ngwa [ 
MTN Cameroon ]
Sent: Tuesday, March 30, 2021 12:11 PM
To: a...@ietf.org
Subject: [Apn] SRv6 Service Programming using TLV

Hi all,

Anybody knows about this demo (youtube link below) ? Would you like to 
introduce a bit more about the use case scenario? It seems to use the argument 
field and SRH TLV to carry the protocol.

This video was published in 2019. Any new updates on it would be very 
appreciated.

https://www.youtube.com/watch?v=NCZzhdu1OCE


[cid:image001.jpg@01D72659.37D3EF20]
​Warm regards,​
Luc‑Fabrice

Ndifor
Specialist ‑ IP Access and Data center
luc-fabrice.ndi...@mtn.com
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 |
mtn.cm
This email is confidential. If you have received it in error, you are on notice 
of its status. Please notify ​the ​​sender immediately by
​reply email and then delete this message from your system. Please do not copy 
it ​or use it for any purpose or disclose its content
​to any other person as to do so could be a breach of ​confidentiality.
​
Please be informed that no employee or agent is authorized to conclude any 
legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in 
writing ​by an MTN Cameroon authorized officer. In no event
​will this email or its content be construed as a written ​approval.
[cid:image002.jpg@01D72659.37D3EF20]

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

Re: [spring] Completion of WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Francois Clad (fclad)]

Hi Jim, chairs,

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

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Thursday, 11 February 2021 at 18:06
To: James Guichard , spring@ietf.org 

Cc: spring-cha...@ietf.org 
Subject: [spring] Completion of WG Adoption Call for 
draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

This email ends the 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/.

Having reviewed all of the responses, the chairs believe that enough support 
was received to adopt this document into the WG. However, while the document is 
informational in nature, it does have a normative dependency on 
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/
 which will need to successfully complete WG LC before this document will be 
able to progress from the WG queue. The chairs feel that more work is necessary 
in terms of definition and interoperability of resource-aware SIDs. In addition 
several comments were received during the adoption call that will need to be 
addressed as the document progresses through the WG process. Further, the 
chairs would like to make it clear that adopting an informational document that 
proposes a particular solution which utilizes resource-aware SIDs does *not* 
preclude future adoption of other documents which propose a different solution 
if the trade-offs are significantly different.

Authors, please resubmit the document as draft-spring-sr-for-enhanced-vpn-00 
and also provide explicit confirmation as to whether you are aware of any IPR 
related to this document.

Regards,

Jim, Joel & Bruno


From: James Guichard 
Sent: Wednesday, January 27, 2021 5:47 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
 ending February 10th 2021.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. 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.

Thanks!

Jim, Bruno & Joel



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

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Francois Clad (fclad)]

Hi chairs, WG,

Support as a co-author.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Wednesday, 27 January 2021 at 12:47
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
February 10th 2021.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. 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.

Thanks!

Jim, Bruno & Joel



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

Re: [spring] General Proxy behavior in SR Service Programming

[Francois Clad (fclad)]

Hi Joel,

Thank you for your email.

A proxy and its associated SF can be seen from the network as a single entity: 
a packet enters this entity from the network, gets processed by the SF, and 
exits towards the network. The packet modifications that occur between the 
entry and exit of this entity are compliant with existing standards.

Whatever happens between the proxy and SF is internal processing and invisible 
to the network. However, a network operator or controller needs some 
information about the proxy’s internal behavior to determine an appropriate 
SID-list through the SF and possibly configure the proxy.

Cheers,
Francois


On 25/07/2020 20:23, "spring on behalf of Joel M. Halpern" 
 wrote:



Let me start by saying that I understand and support what the draft is 
trying to do.  While I like SFC, I am under no illusions that it is or 
should be the only answer to service chaining / service programming.

Further, I understand what the proxies are for.  They seem necessary. 
To deploy this stuff, we have to be able to work with older equipment. 
Proxies seem the best way to do so.

The document is even clear that  proxy is a new kind of thing.  Good.

In order to do its job, and as I read this document, the SR proxies (of 
various kinds) violate the rules for MPLS processing, SRH processing, 
and IPv6 processing at various points.  They have to.

It seems to me that we need to accept this requirement, and state it 
clearly.  Most likely, this would suggest that we will want some form of 
signoff from the MPLS and 6man working groups that these violations, for 
these specific reasons, are acceptable to the community.  Personally, I 
would rather have the discussion soon, rather than pretending it is a 
non-issue and having the discussion during IETF last call.

Maybe I am misreading, and things are less conflicted.  That would be great.

Yours,
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] Dynamic Proxy in SR service programming

[Francois Clad (fclad)]

Hi Joel,

Thank you for your email.

At high-level, the dynamic proxy combines a caching mechanism with a mapping 
scheme that associates cache entries to packets or flows.

There are many possible mapping schemes, each has pros and cons that make it 
more suitable in some environments and less in others. This I-D describes a 
simple one, which is interface-based (or VLAN-based), and implies that a 
dynamic proxy SID is used in a single SID-list at a time. This makes it 
particularly suitable for container-based environments, where VNFs are spawned 
on a per-SFC basis.

In different environments, other mapping techniques could be used, such as 
those described in draft-song-sfc-legacy-sf-mapping.

Cheers,
Francois


On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" 
 wrote:

Thank you.  That does clarify, and it would probably be good to be 
explicit in the document.  (The restriction makes sense, we just need to 
be clear.)

Yours,
Joel

On 7/25/2020 8:31 PM, Stefano Salsano wrote:
> Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
>> 
>>
>> In looking at the description of the dyanmic proxy behavior, I was 
>> reminded of a problem that the SFC working group wrestled with and 
>> never resolved to our satisfaction.  (In the SFC case, since we were 
>> not specifying the behavior of the proxy, we could leave it to 
>> implementors.   This document seems to be more specific.)
>>
>> As I understand the draft, the dyanicm proxy for a non-SR aware 
>> service function can be handling packets subject ot multiple service 
>> policies. That is desirable.  These separate policies will have 
>> separate cache entries.  Also good.
>> But as far as I can tell, the re-attachment of the cached header to 
>> the returned packet (from the non-SR aware SF) is done based on first 
>> come, first cache.
> 
> Hi Joel,
> 
> I'm speaking as an author of draft-ietf-spring-sr-service-programming-02 
> (but I do not know if my opinion is agreed by all the authors)
> 
> my understanding of the dynamic proxy scenario is that a given "non-SR 
> aware service function" (aka "legacy VNF") can be associated with a 
> single Service Chain at a given time
> 
> so you can dynamically change the Service Chain by sending a Packet-2 
> with a different SR policy with respect to Packet-1, but this is meant 
> to change the Service Chain for the following packets of the flow, 
> rather than to operate on a packet-by-packet basis
> 
> you are right that operating on a packet-by-packet basis leads to 
> inconsistent behavior!
> 
> In draft-ietf-spring-sr-service-programming-02, the following limitation 
> is associated to the static SR proxy, but it also applies to the dynamic 
> proxy:
> 
> However, a static SR proxy
> segment can be used in only one service policy at a time.  As opposed
> to most other segment types, a static SR proxy segment is bound to a
> unique list of segments, which represents a directed SR service
> policy.  This is due to the cached SR information being defined in
> the segment configuration.  This limitation only prevents multiple
> segment lists from using the same static SR proxy segment at the same
> time, but a single segment list can be shared by any number of
> traffic flows.
> 
> This is he description of the dynamic proxy:
> 
> The dynamic proxy is an improvement over the static proxy that
> dynamically learns the SR information before removing it from the
> incoming traffic.
> 
> Maybe it would be better to explicitly clarify that the same limitation 
> of the static SR proxy is applicable: "only one service policy at a 
> time"... the difference is that you can change this association 
> dynamically, e.g. in the order of few seconds but NOT on a 
> packet-by-packet basis
> 
> hope that it clarifies...
> 
> ciao
> Stefano
> 
> 
>> What happens if, due to differences in internal processing, packets 
>> from different service policies get swapped in time.  So packets go in 
>> Packet-1, Packet-2, but come out Packet-2, Packet-1.  The text seems 
>> to result in the proxy reattaching the SR information to the wrong 
>> packets?
>>
>> Am I misreading the text?
>>
>> Depending upon ones, reading, this may apply to a case where a single 
>> device is service as multiple static proxies for a single non-SR aware 
>> SF.  It was not clear if that was intended to be allowed, but if so 
>> the same issue would seem to apply.
>>
>> Yours,
>> Joel
>> 
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
> 

Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang

[Francois Clad (fclad)]

Hi,

I support the adoption of this draft.

The definition of a YANG data model for the SR policy architecture is an 
important work item for this WG.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Monday 13 July 2020 at 17:38
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-sr-policy-yang/ ending 
Monday 27th July 2020.

Please speak up if you support or oppose adopting this document into the WG. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno



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

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Francois Clad (fclad)]

Hi,

As a co-author, I support the adoption of this draft.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Wednesday 15 July 2020 at 13:17
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
Wednesday 29th July 2020.

Please speak up if you support or oppose adopting this document into the WG. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno



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

Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

[Francois Clad (fclad)]

Hi,

I support the adoption of this draft.

The definition of a YANG data model for SRv6 is an important work item and this 
draft is well aligned with draft-ietf-spring-srv6-network-programming.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Monday 13 July 2020 at 23:54
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending Monday 
27th July 2020.

Please speak up if you support or oppose adopting this document into the WG. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno




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

[spring] Compressed SRv6 Segment List Encoding in SRH

[Francois Clad (fclad)]

Dear SPRING,

The authors of draft-filsfils-spring-net-pgm-extension-srv6-usid and 
draft-cl-spring-generalized-srv6-for-cmpr have been working together on a joint 
document that describes how compressed SRv6 Segment-List encoding in the SRH 
can be achieved without any change to the SRv6 data plane or control plane. The 
new draft link is as follows:

https://www.ietf.org/internet-drafts/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01.txt

In this draft, we leverage the notions of SID function and argument defined in 
draft-ietf-spring-srv6-network-programming to compress the SRv6 Segment List 
encoding in the SRH. The compressed encoding is achieved through two new 
flavors of the base Network Programming behaviors (End, End.X and End.T), named 
NEXT-C-SID and REPLACE-C-SID.
 
Thanks,
 
Weiqiang Cheng
Clarence Filsfils
Zhenbin Li
Dennis Cai
Daniel Voyer
Francois Clad (editor)
Shay Zadok
James N Guichard
Liu Aihua

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

Re: [spring] I-D Action: draft-ietf-spring-sr-service-programming-02.txt

[Francois Clad (fclad)]

Dear all,

We have just updated the SR Service Programming draft with the following 
changes:
 - Aligned SRv6 pseudocodes for static, dynamic and masquerading proxies with 
draft-ietf-6man-segment-routing-header and 
draft-ietf-spring-srv6-network-programming
 - For consistency, aligned SR-MPLS pseudocodes to follow a similar model
 - Added missing pseudocode for the caching flavor of the masquerading proxy
 - Added code points in the IANA section for all flavors of the masquerading 
proxy (similar to what is done in draft-ietf-spring-srv6-network-programming)
 - Various editorial fixes (text clarification, removal of redundancies, 
terminology fixes,…)

Any feedback welcome.

Thanks,
Francois (on behalf of my co-authors)


On 09/03/2020 18:50, "spring on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Source Packet Routing in Networking WG of 
the IETF.

Title   : Service Programming with Segment Routing
Authors : Francois Clad
  Xiaohu Xu
  Clarence Filsfils
  Daniel Bernier
  Cheng Li
  Bruno Decraene
  Shaowen Ma
  Chaitanya Yadlapalli
  Wim Henderickx
  Stefano Salsano
Filename: draft-ietf-spring-sr-service-programming-02.txt
Pages   : 39
Date: 2020-03-09

Abstract:
   This document defines data plane functionality required to implement
   service segments and achieve service programming in SR-enabled MPLS
   and IPv6 networks, as described in the Segment Routing architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-service-programming/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-sr-service-programming-02

https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-02

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-service-programming-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/


___
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] Can features described by draft-ietf-spring-sr-service-programming-01 be supported by draft-ietf-spring-srv6-network-programming-08?

[Francois Clad (fclad)]

Dear Linda,

Thank you for your email.

Please see inline.

Thanks,
Francois


From: Linda Dunbar 
Date: Friday 17 January 2020 at 01:31
To: "draft-ietf-spring-sr-service-programm...@ietf.org" 

Cc: SPRING WG 
Subject: Can features described by draft-ietf-spring-sr-service-programming-01 
be supported by draft-ietf-spring-srv6-network-programming-08?

Authors of draft-ietf-spring-sr-service-programming-01:

“draft-ietf-spring-sr-service-programming” specifies Service SIDs to be 
embedded into the SID list. Does it make the SID list even longer? For example, 
 if a packet needs to be steered through the network by 3 SIDs (S1, S2, S3), 
Service SIDs will be the additional SIDs to be added to the packet header?

It is by including a service SID in the SID-list that you can steer packets 
through the network function associated with this service SID. Regarding your 
specific example, if you add service SIDs in a SID-list that already contains 
other types of SIDs (e.g., topological ones), then it will indeed make your 
SID-list longer.

It seems straight forward for draft-ietf-spring-srv6-network-programming to add 
an instruction to forward the packet to a specific service Function.  Why not 
using draft-ietf-spring-srv6-network-programming to steer packets to specific 
service functions?
What features specified by draft-ietf-spring-sr-service-programming that can’t 
be achieved by draft-ietf-spring-srv6-network-programming?

While you may be able to perform some basic service chaining with the 
functionalities defined in other drafts, many service chaining use-cases 
require more than that. For example, some service chaining use-cases involve 
legacy network functions (SR-unaware) that are not able to process an SR packet 
(SR-MPLS or SRv6) or the usage of metadata. 
draft-ietf-spring-sr-service-programming defines the additional data plane 
procedures and protocol extensions to support these use cases for both SR-MPLS 
and SRv6.

Some minor questions:  What is the ENH in Section 6.1.2? You have ENH = 59, ENH 
= 4,  Are  you talking the Ethernet frames being encapsulated by SRH header?
The inner payload are IP frames, aren’t they?

Depending on the use-case and the behavior, the inner payload can be Ethernet, 
IPv4, IPv6, or a transport layer header.

ENH is an old terminology that is really the Upper-layer header type (inner 
payload type). The same applies to value 59, which should be changed to “TBD1” 
from draft-ietf-spring-srv6-network-programming until the appropriate value is 
assigned by IANA. Thank you for raising that point. We will correct that in the 
next revision of the draft.


Thank you very much,

Linda Dunbar



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

Re: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

[Francois Clad (fclad)]

Hi,

Support.

Thanks,
Francois

Le 3 janv. 2020 à 03:01, Pablo Camarillo (pcamaril)  a 
écrit :


Happy New Year.

I support.

Thanks,
Pablo.

From: spring  on behalf of "bruno.decra...@orange.com" 

Date: Thursday, 19 December 2019 at 17:54
To: SPRING WG 
Subject: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early 
Allocation Call


Hi SPRING WG,



This begins a 2 week Early Allocation call for a “Ethernet” value from the 
"Protocol Numbers" registry.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml



In parallel of the Working Group Last Call which is currently running, the 
authors are requesting for early code point allocation from IANA as 
implementations are under way.



The criteria for early allocation are:

   a.  The code points must be from a space designated as "RFC

   Required", "IETF Review", or "Standards Action".  Additionally,

   requests for early assignment of code points from a

   "Specification Required" registry are allowed if the

   specification will be published as an RFC.



   b.  The format, semantics, processing, and other rules related to

   handling the protocol entities defined by the code points

   (henceforth called "specifications") must be adequately described

   in an Internet-Draft.



   c.  The specifications of these code points must be stable; i.e., if

   there is a change, implementations based on the earlier and later

   specifications must be seamlessly interoperable.



   d.  The Working Group chairs and Area Directors (ADs) judge that

   there is sufficient interest in the community for early (pre-RFC)

   implementation and deployment, or that failure to make an early

   allocation might lead to contention for the code point in the

   field.

https://tools.ietf.org/html/rfc7120#section-2



I believe the above conditions are met. (minus the AD judgement which is 
further down in the process)



As a reminder, this topic has mainly been discussed following IETF 105 
(Montréal) both during the meeting and on the mailing list.

During IETF 106 it has been discussed in the IntArea WG. 
https://datatracker.ietf.org/meeting/106/proceedings#intarea



Note that this code point is not to be specific to SRv6. Depending on AD 
guidance, this specific code point even be moved from 
draft-ietf-spring-srv6-network-programming into a specific 1 page draft.



If you support early adoption,  please include “support” along with any 
comments about the draft’s technical solution.



If you do not support early allocation, please include “no support” in your 
email and indicate why.



Thank you,

--Bruno


_



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
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR poll for draft-ietf-spring-srv6-network-programming

[Francois Clad (fclad)]

Hi,

As a contributor, I am not aware of any undisclosed IPR related to this 
document.

Thanks,
Francois

On 05/12/2019 17:54, "spring on behalf of bruno.decra...@orange.com" 
 wrote:

Hi SPRING WG,

In parallel to the WGLC for draft-ietf-spring-srv6-network-programming, we 
would like to poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-srv6-network-programming [1] please respond to this email. If 
you are aware of IPR, please indicate whether it has been
disclosed in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 
provide more details).

If you are an *author or contributor* please respond to this email 
regardless of whether or not you're aware of any IPR. 

This document will not advance until IPR confirmations have been received 
from all authors and contributors.

Thank you,
Bruno

[1] 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05



_

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


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

Re: [spring] hop limit decrement on SRv6 proxies

[Francois Clad (fclad)]

Dear Nakamura-san,

Many thanks for reviewing this draft and experimenting on SRv6 service chaining.

I understand that the current version of the draft is not very clear regarding 
IPv6 hop limit updates and will work towards improving this aspect in the next 
revision of the draft.

In the specific case of the SRv6 masquerading proxy (End.AM) that you mention 
in section 4.4 of draft-upa-srv6-service-chaining-exp, each traversal of the 
proxy is one IP hop. The proper behavior should thus be to decrement the hop 
limit each time the packet traverses the proxy.

Regards,
Francois

On 03/11/2019 18:48, "spring on behalf of Ryo Nakamura" 
 wrote:


Dear authors of sr-service-programming daft,

Through an experiment of SRv6 service chaining, we found that there were 
variations on hop limit decrement behaviors of SRv6 proxies, as noted in 
Section 4.4 in draft-upa-srv6-service-chaining-exp. An implementation decreases 
hop limit of IPv6 headers when sending packets to IFACE-OUT, and another 
implementation does not decrease it on IFACE-OUT. Thus, hop limit values of 
packets varied depending on the proxy implementations.

These variations would complicate traceroute results, for instance. Thus, 
we suggest clarifying how to decrement hop limit in the sr-service-programming 
draft. Should one proxying decrement hop limit twice or once?

Regards,
Ryo Nakamura
___
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: draft-guichard-spring-nsh-sr

[Francois Clad (fclad)]

Support adoption.

Thanks,
Francois

From: spring  on behalf of Rob Shakir 

Date: Thursday 27 June 2019 at 08:15
To: SPRING WG List 
Subject: [spring] WG Adoption Call: draft-guichard-spring-nsh-sr

Hi SPRING WG,

This email initiates a two week working group adoption call for 
draft-guichard-spring-nsh-sr. This follows the discussion that we had in the 
last few IETF meetings, and particularly the focused discussion we had at IETF 
104 regarding service chaining and SPRING.

Please indicate your support, comments, or objections for adopting this draft 
by Wednesday July 10th, 2019.. We are particularly interested in hearing from 
WG members who are not authors of this draft, and those folks that are willing 
to spend time working on this draft after adoption.

We are also looking for volunteers who can provide a technical review of the 
content of the draft at a later stage of its progress through the working group 
(e.g., before WGLC).

In parallel - we'll send an IPR poll to the working group and authors. The 
currently disclosed IPR can be found in the 
datatracker.

Thanks!
Rob & Bruno.


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

Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[Francois Clad (fclad)]

Hi,

I am not aware of any IPR other than already disclosed.

Thanks,
Francois

From: spring  on behalf of Bruno Decraene 

Date: Wednesday 13 March 2019 at 19:50
To: SPRING WG 
Cc: "draft-filsfils-spring-srv6-network-programm...@ietf.org" 

Subject: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming


Hi authors, SPRING WG,



In parallel to the call for adoption for 
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for 
IPR.



If you are aware of IPR that applies to 
draft-filsfils-spring-srv6-network-programming please respond to this email.

If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).



If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond only if you 
are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.



Thank you,



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.


_



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] IPR Poll for draft-filsfils-spring-segment-routing-policy

[Francois Clad (fclad)]

I’m not aware of any IPR other than already disclosed at 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-filsfils-spring-segment-routing-policy

Francois

On 16 May 2018, at 18:15, 
bruno.decra...@orange.com wrote:

[+ authors]

I'm not aware of any IPR that applies to this draft

--Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, May 16, 2018 5:20 PM
To: SPRING WG List
Subject: [spring] IPR Poll for draft-filsfils-spring-segment-routing-policy

Hi SPRING WG,

In parallel to the call for adoption for 
draft-filsfils-spring-segment-routing-policy, we would like to poll for IPR.

If you are aware of IPR that applies to 
draft-filsfils-spring-segment-routing-policy please respond to this email. If 
you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).

If you are an author or contributor please respond to this email regardless of 
whether or not you're aware of any IPR. If you are not an author or 
contributor, please explicitly respond only if you are aware of IPR that has 
not yet been disclosed.

This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.

Thanks,
Bruno & Rob.

_

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] [sfc] [mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Francois Clad (fclad)]

Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

I, too, hope we can move to a technical discussion of the differences between 
the proposals

The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu pointed out several times.

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.

To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.

Thanks,
Francois


and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step would be to read (you know, like all the words :-) what is in the drafts.

However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight.

He said...

> From IETF process viewpoint, this call for adaption is like putting the "cart 
> ahead of the horse."
> MPLS WG comes last in the process after there is an agreement from Spring and 
> SFC groups
> on the need for MPLS data plane changes proposed by the draft. I raised this 
> point at the mic
> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at 
> the last stage
> in the process; expert to review this work does not sit in the MPLS WG.

According to the minutes, Zafar said...

| Zafar Ali: before defining the solution, is this the right approach in SFC? 
Starting
| in MPLS WG is wrong thing to do.

And I responded...

| Adrian: This was already presented in SFC WG today.

In the SFC WG I said...

| - The draft discusses how MPLS can be used for SFC. It is being discussed in 
the
|MPLS working group.
| - We are looking at environments in which deployed MPLS routers can be used
|for creating an SFC, rather than using NSH.

If you want my opinion:
- The SFC WG is chartered to work on NSH only
- The MPLS WG is chartered to work on MPLS
- This draft asks for MPLS code points so can only be in MPLS
- This draft must be reviewed in SFC and SPRING as it progresses and
   certainly at WG last call

Adrian

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
Importance: High

Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,

I would like to draw your attention to the serious issue raised by Xiaohu and 
Francois.

Summary:

Please note that this working group adaption against the IETF process and its 
spirit. Please recall the adaption call.

Details:

Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we 
discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc 
and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS 
WG. There was the specific conversation on which WG the work belongs, and the 
assumed follow-up was for the chairs and ADs to have the discussion on home for 
these drafts.

From IETF process viewpoint, this call for adaption is like putting the "cart 
ahead of the horse." MPLS WG comes last in the process after there is an 
agreement from Spring and SFC groups on the need for MPLS data plane changes 
proposed by the draft. I raised this point at the mic at SFC WG meeting at 
IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the 
process; expert to review this work does not sit in the MPLS WG.

The drafts also did not stay dormant after IETF100. There were email 
conversations among the authors of the concerned drafts 
(https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA).

Authors of draft-xu- and draft-clad- followed the proper IETF process, 
discussed and merged the contents. They published 
draft-xuclad-spring-sr-service-chaining-01 and asked WG for a "presentation 
slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to 
force this "WG adaption call"!

One also has to question the timing of this adaption call when the WGs are 
meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to make 
use of the face-to-face to do the right thing, especially when we are meeting 
in two weeks?

In the light of 

Re: [spring] [mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Francois Clad (fclad)]

Hi Xiaohu, all,

I agree with the point raised by Xiaohu. The draft-farrel-mpls-sfc is copying 
ideas described in draft-xu-mpls-service-chaining. Please note that the work in 
draft-xu-mpls-service-chaining started one year before draft-farrel-mpls-sfc.

At IETF100, three drafts in this area were discussed / presented:
- draft-xu-mpls-service-chaining
- draft-farrel-mpls-sfc
- draft-clad-spring-segment-routing-service-chaining

There was discussion over the mic on the right home for these drafts among SFC, 
SPRING and MPLS, but no consensus was reached.

As Xiaohu mentioned, draft-xu-mpls-service-chaining and 
draft-clad-spring-segment-routing-service-chaining have later merged as 
draft-xuclad-spring-sr-service-chaining. We have also requested a slot for 
presenting this draft during the upcoming IETF meeting.

In this context, we believe that asking for WG adoption for one of these drafts 
is premature.

Thanks,
Francois

On 7 Mar 2018, at 01:13, 徐小虎(义先) 
> wrote:

Hi all,

As I had pointed out at the last IETF meeting, section 6 of this draft has an 
serious overlap with 
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that has now been 
updated by 
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with a 
merge with draft-clad-spring-segment-routing-service-chaining.

Hence, I'm very interesting to know the intention of such rewritting of a given 
mechanism that has been described in another draft. Is there any special 
nutrition?

Best regards,
Xiaohu
--
发件人：IETF Secretariat 
>
发送时间：2018年3月6日(星期二) 22:09
收件人：draft-farrel-mpls-sfc 
>; mpls 
>; mpls-chairs 
>
主　题：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For 
Adoption By WG Issued"


The MPLS WG has placed draft-farrel-mpls-sfc in state
Call For Adoption By WG Issued (entered by Loa Andersson)

The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/

___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
___
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] New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

[Francois Clad (fclad)]

Hi Jim,

Well read. This static proxy is the base mechanism that matches current state 
of the art. It has the same scaling limitations as NSH (state in the fabric), 
but does not require separate encapsulations for traffic engineering and 
service chaining. With this integrated solution, the same encapsulation can 
combine TE and service segments.

The static and dynamic proxies can support multiple service chains by using 
different SID values and interfaces to differentiate the chains. The dynamic 
proxy thus caches the received SRH on a per chain basis. (see sections 5.1 and 
5.2)

Furthermore, the other proxy mechanisms described in this draft aim at 
addressing the scaling issues by removing state from the proxy. We also expect 
that services will be eventually updated with native SR support. The proposed 
model enables these SR-native services to be transparently combined with 
proxied ones or segments of any other type in the same encapsulation.

I hope that answers your questions.

Thanks,
Francois

On 18 Oct 2017, at 20:04, James N Guichard 
<james.n.guich...@huawei.com<mailto:james.n.guich...@huawei.com>> wrote:

Hi Francois,

Reading through the description for static proxy I am given to believe that the 
cache is preconfigured with the appropriate SR stack to be applied to traffic 
coming back from the service; if this is correct presumably this means that you 
can only support a single service-chain so that the correct SR stack can be 
pushed back on to the packet; is this correct? I note that you then describe a 
dynamic proxy that caches the received SR stack for a given flow so that it can 
be reapplied to the traffic coming back from the service; again, if you want to 
share that service across multiple service chains, is the assumption that you 
will cache the received SR stack on a per-packet basis so that you reapply the 
correct outgoing SR stack?

Thanks,

Jim

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Francois Clad (fclad)
Sent: Wednesday, October 18, 2017 10:47 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

We have just submitted draft-clad-spring-segment-routing-service-chaining-00.

Any feedback is welcome.

Regards,
Francois

On 06/10/2017, 21:32, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:


   A new version of I-D, 
draft-clad-spring-segment-routing-service-chaining-00.txt
   has been successfully submitted by Francois Clad and posted to the
   IETF repository.

   Name: draft-clad-spring-segment-routing-service-chaining
   Revision: 00
   Title: Segment Routing for Service Chaining
   Document date: 2017-10-06
   Group: Individual Submission
   Pages: 24
   URL:
https://www.ietf.org/internet-drafts/draft-clad-spring-segment-routing-service-chaining-00.txt
   Status: 
https://datatracker.ietf.org/doc/draft-clad-spring-segment-routing-service-chaining/
   Htmlized:   
https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining-00
   Htmlized:   
https://datatracker.ietf.org/doc/html/draft-clad-spring-segment-routing-service-chaining-00


   Abstract:
  This document defines data plane functionality required to implement
  service segments and achieve service chaining with MPLS and IPv6, as
  described in the Segment Routing architecture.




   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<http://tools.ietf.org>.

   The IETF Secretariat



___
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

[spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

[Francois Clad (fclad)]

Hello,

We have just submitted draft-clad-spring-segment-routing-service-chaining-00.

Any feedback is welcome.

Regards,
Francois

On 06/10/2017, 21:32, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, 
draft-clad-spring-segment-routing-service-chaining-00.txt
has been successfully submitted by Francois Clad and posted to the
IETF repository.

Name:   draft-clad-spring-segment-routing-service-chaining
Revision:   00
Title:  Segment Routing for Service Chaining
Document date:  2017-10-06
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-clad-spring-segment-routing-service-chaining-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-clad-spring-segment-routing-service-chaining/
Htmlized:   
https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-clad-spring-segment-routing-service-chaining-00


Abstract:
   This document defines data plane functionality required to implement
   service segments and achieve service chaining with MPLS and IPv6, as
   described in the Segment Routing architecture.


  


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