Re: [spring] Progressing Standardizing SR over IPv6 compression

[Loa Andersson]

Dhairs, working group,

I agree with Matthew, we should standardize one single data plane 
behavior for IPv6 compression.



/Loa
> compressing SRv6 information

On 18/08/2021 19:35, Bocci, Matthew (Nokia - GB) wrote:

Joel

Yes, I believe the WG should standardize a single data plane solution.

This will enable to the WG and industry to move forward and enable 
vendors to implement a single interoperable solution. It reduces overall 
solution complexity and greatly benefits deployments.


Based on the experience of multiple working groups, it is hugely 
beneficial to have a single data plane solution on which we can focus 
our efforts.


Thanks

Matthew

*From: *spring  on behalf of Joel M. Halpern 


*Date: *Wednesday, 4 August 2021 at 19:52
*To: *spring@ietf.org 
*Subject: *[spring] Progressing Standardizing SR over IPv6 compression

The SPRING Working Group Chairs thank the design team for their efforts
on the requirements and analysis drafts.  The question of how the
working group wants to progress that part of the work will be the topic
for a separate email a bit later.

Right now, we are hearing the discussion about how many solutions, and
the perspectives being expressed.  While the topic was well-raised, the
discussion to date has not been structured in a way that makes clear to
everyone what the purpose is.  In particular, the chairs have decided to
re-ask the question.  We ask that even those who have responded in the
discussion respond to this thread.  Preferably with both what their
opinion is and an explanation of why.

The question we are asking you to comment on is:

Should the working group standardize one data plane behavior for
compressing SRv6 information?

Please speak up.  We are looking to collect responses until close of
business PDT on 20-August-2021.

Thank you,
Joel, Jim, and Bruno

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



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



--

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

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

[spring] poll on meeting time for the Open MPLS Design Team

[Loa Andersson]

Design Team,

When we renewed the the WebEx booking for the weekly meetings of the 
MPLS Open DT I managed to confuse things.


I asked for 4pm CET, and that is what I got, only that we are now 
running daylight saving time (CEST), and 4 pm CET is 5pm CEST.


We discussed this at the meeting on last Thursday and said that we poll 
the attendees if they want to continue as the meeting is set up now (5pm 
CEST) or if we should go back to 4pm CEST.


Please respond to the mpls wg chairs (mpls-cha...@ietf.org), copy the 
list (mpls list) only if want express an opinion.


/Loa
mpls wg co-chairs
--

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

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

Re: [spring] A possible additional topic for the discussion by the MPLS Open DT.

[Loa Andersson]

Greg,

Sure, just prepare a detailed walk through, discussing what is new, what 
is different, what the architectural implications are, backwards 
compatibility, etc.


/Loa

On 27/04/2021 05:11, gregory.mir...@ztetx.com wrote:

Hi Loa,

thank you for your kind offer. Would posting the draft by Wednesday, 
before the meeting on Thursday be acceptable?



Regards,

Greg Mirsky


Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline 
Product R Institute/Wireline Product Operation Division




E: gregory.mir...@ztetx.com <mailto:gregory.mir...@ztetx.com>
www.zte.com.cn <http://www.zte.com.cn/>

Original Mail
*Sender: *LoaAndersson
*To: *Greg Mirsky;MPLS Working 
Group;mpls;spring;spring-cha...@ietf.org;pwe3;pwe3-cha...@tools.ietf.org;

*CC: *huubatw...@gmail.com;Stewart Bryant;Italo Busi;Adrian Farrel;
*Date: *2021/04/26 01:25
*Subject: **Re: [spring] A possible additional topic for the discussion 
by the MPLS Open DT.*

Greg,

Do you plan to post this - if you do so timely I'm prepared to give you
30 min for a walk through at the DT meeting on Tuesday.

/Loa

On 20/04/2021 21:42, Greg Mirsky wrote:
 > Dear All,
 > Stewart, Adrian, Italo, Huub, and I had discussed the question of
 > multiple GALs in an MPLS label stack after the IETF-110. The question is
 > directly related to the mechanism proposed in
 > draft-lm-mpls-sfc-path-verification
 > <https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/>.
 > I've put together a short draft (attached). It appears, that this issue
 > may fit in the scope of the work of the MPLS Open DT. Appreciate
 > your thoughts on whether it can be discussed at one of the Open DT
 > meetings. Also, welcome your comments, suggestion on the attached draft.
 >
 > Regards,
 > Greg (on behalf of the group)

--

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

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



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



--

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

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

Re: [spring] A possible additional topic for the discussion by the MPLS Open DT.

[Loa Andersson]

Greg,

Sure, just prepare a detailed walk through, discussing what is new, what 
is different, what the architectural implications are, backwards 
compatibility, etc.


/Loa


On 27/04/2021 05:11, gregory.mir...@ztetx.com wrote:

Hi Loa,

thank you for your kind offer. Would posting the draft by Wednesday, 
before the meeting on Thursday be acceptable?



Regards,

Greg Mirsky


Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline 
Product R Institute/Wireline Product Operation Division




E: gregory.mir...@ztetx.com <mailto:gregory.mir...@ztetx.com>
www.zte.com.cn <http://www.zte.com.cn/>

Original Mail
*Sender: *LoaAndersson
*To: *Greg Mirsky;MPLS Working 
Group;mpls;spring;spring-cha...@ietf.org;pwe3;pwe3-cha...@tools.ietf.org;

*CC: *huubatw...@gmail.com;Stewart Bryant;Italo Busi;Adrian Farrel;
*Date: *2021/04/26 01:25
*Subject: **Re: [spring] A possible additional topic for the discussion 
by the MPLS Open DT.*

Greg,

Do you plan to post this - if you do so timely I'm prepared to give you
30 min for a walk through at the DT meeting on Tuesday.

/Loa

On 20/04/2021 21:42, Greg Mirsky wrote:
 > Dear All,
 > Stewart, Adrian, Italo, Huub, and I had discussed the question of
 > multiple GALs in an MPLS label stack after the IETF-110. The question is
 > directly related to the mechanism proposed in
 > draft-lm-mpls-sfc-path-verification
 > <https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/>.
 > I've put together a short draft (attached). It appears, that this issue
 > may fit in the scope of the work of the MPLS Open DT. Appreciate
 > your thoughts on whether it can be discussed at one of the Open DT
 > meetings. Also, welcome your comments, suggestion on the attached draft.
 >
 > Regards,
 > Greg (on behalf of the group)

--

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

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



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



--

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

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

Re: [spring] A possible additional topic for the discussion by the MPLS Open DT.

[Loa Andersson]

Greg,

Do you plan to post this - if you do so timely I'm prepared to give you 
30 min for a walk through at the DT meeting on Tuesday.


/Loa

On 20/04/2021 21:42, Greg Mirsky wrote:

Dear All,
Stewart, Adrian, Italo, Huub, and I had discussed the question of 
multiple GALs in an MPLS label stack after the IETF-110. The question is 
directly related to the mechanism proposed in 
draft-lm-mpls-sfc-path-verification 
<https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/>. 
I've put together a short draft (attached). It appears, that this issue 
may fit in the scope of the work of the MPLS Open DT. Appreciate 
your thoughts on whether it can be discussed at one of the Open DT 
meetings. Also, welcome your comments, suggestion on the attached draft.


Regards,
Greg (on behalf of the group)


--

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

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

[spring] Agenda for tonites meeting of the Open MPLS WG DT

[Loa Andersson]

Working Groups,

Apologies, I will stop spraying MPLS DT info across every conceivable WG 
mailing list.


There fore the agenda just went out to the MPLS WG mailing list. Go find 
it there.


/Loa
--

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

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

[spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

[Loa Andersson]

MPLS, PALS, DETNET and SPRING working groups,

Note: This message is sent to four working groups, please limit 
responses to the mpls wg mailing list only.


All members of the four working group are invited to participate in an 
open MPLS wg design team to address the work that was discussed in the 
joint meeting at IETF 110


Below follows "notes" from a meeting between chairs of the four working 
groups 2021-03-22. It outlines how we initially will take on the work.


---  meeting notes   ---


Continue the work the joint meeting at IETF 110.


Working Group Chairs from MPLS, PALS, SPRING and DETNET met
2021-03-22 to discuss how to follow up the joint meeting
at IETF 110.

Participation:
------

  Loa Andersson (mpls)
  Tarek Saad (mpls)
  Stewart Bryant (pals)
  Andy Malis (pals)
  Joel Halpern (spring)
  Lou Berger (detnet)

We discussed three themes
-

- what to do next
- how to document the output from the joint meeting
- how to organize the work that starts here

We agreed
=

- that the work starting here is part of the MPLS architecture  and in
  the end might lead to updates - that this is work that should be
  coordinated by the mpls working group and that discussion working
  group adoption and the discussion should be taken to the MPLS WG
  mailing list.

We agreed with the summary from the joint meeting
-

- that tt is important that MPLS grows and develops to support the new
  needs of network operators. The alternative to such development is
  stagnation and a path to obsolescence.

- that is important that any change does not adversely impact the
  operation of legacy equipment installed in the same network as the n
  new functionality.

- it is important that any change is both forwards and backwards
  compatible. i.e. that any change does not limit the ability for
  further future development of MPLS.

- it is important that any change be practical on the forwarding
  technology likely to be deployable in the reasonably near future.

- it is important that we minimize the number of changes needed to
  support the new needs but making that change an elegant approach
  that satisfies as many of the new needs as possible.

- there is sufficient interest and urgency in the need for new features
  that we need to work on this between meetings to progress at an
  acceptable rate.

We also agreed on some practical things
---

- the list (possibly incomplete) of proposals in Stewart's slides
  has been updated to a short draft to serve as input to this work
  (draft-bryant-mpls-dev-primer-00.txt).

- the work will be divided into two "tracks" (1) proposals carrying
  information after the BoS and; (2) proposals carrying info in the
  stack.

- we will hold open design-team meetings, i.e. any member of the four
  working groups are encouraged to participate

- the meeting cycle is 5 weeks:

  -- "week 1" we will have a joint meeting to coordinate between the
 two tracks
  -- "week 2" and "week 4" we will have a track 1 meeting
  -- "week 3" and "week 5" we will have a track 2 meeting
  -- "week 6" = "week 1"; and we start the count over again

We will start  with joint (kick off) meeting April 8. The agenda will be 
prepared during the week of April 5, let us know if there is anything 
you want to discuss. We already now know that we will want to discuss 
Stewart's primer.


Mach will send out WebEx details to all four working groups.

- the over all coordination of this activity will done by Loa, if
  you need a slot in any meting or need to put a discussion point
  on the agenda ping Loa.

- the meetings will be every Thursday at 3pm Central European Time.

/Loa
for(all) the wg-chairs


--

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

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

[spring] Conflict between SPRING and MPLS Monday of IETF 110

[Loa Andersson]

SPRING chairs,

For the upcoming IETF 110 we have a conflict between MPLS and SPRING the 
first afternoon slot (13-15)  on Monday, it is unfortunate but it was 
the best we could do without re-doing the entire agenda.


However you have a second SPRING on Thursday, as much as possible can 
please you steer discussions that you believe are of interest for MPLS 
to your second slot.


Also, at least for some of the SPRING participants I believe that the 
PALS session on Friday (joint with MPLS and DETNET) may be of interest.


/Loa
--

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

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

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Loa Andersson]

Jeff,


On 08/02/2021 14:51, Jeff Tantsura wrote:

Hi Ron,

Very useful document, thanks!

Question wrt processing:
As described in the draft:
“A SID instance is associated with SR-MPLS label stack and outgoing interface.”

I’d think that outgoing interface would be recursively resolved based on the 
top SID (and could change based on topological semantics).
Could you please elaborate?


What exactly do yo mean by "recursively"?

/Loa


Thanks!


Cheers,
Jeff


On Feb 7, 2021, at 08:46, Ron Bonica  
wrote:


Please review and comment


Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky ; Peng Shaofu
; Ron Bonica ; Shaofu Peng
; Shraddha Hegde ; EXT-
zhang.zh...@zte.com.cn 
Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-spring-srv6-end-dtm
Revision:   01
Title:  The SRv6 END.DTM Segment Type
Document date:  2021-02-07
Group:  Individual Submission
Pages:  7
URL:   https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
Htmlized:  https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01
Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-01

Abstract:
   This document describes a new SRv6 segment type, called END.DTM.  The
   END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
   Like any segment type, END.DTM contains a function and arguments.
   The function causes the processing SRv6 node to remove an SRv6 header
   and impose an SR-MPLS label stack.  The arguments determine MPLS-
   label stack contents.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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


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



--

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

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

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

[Loa Andersson]

Working Group,

I have reviewed the draft and believe that it is a good starting point 
for the wg to create the Enhanced VPN standard.


/Loa

On 27/01/2021 19:46, James Guichard wrote:

Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
<https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/> ending 
February 10^th 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



--

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

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

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Loa Andersson]

Working Group,

I support adopting this document.

However I have one question; if it leads to (very small) changes in the 
document, this can be done after the adoption.


I'm looking at

   HMAC-SHA: Consists of two parts
   HMAC: Hashed Message Authentication Code (expanded in the document).
   SHA: Secure Hash Algorithm (not expanded, but on the other hand it an
well-known abbreviation)

When we combine two abbreviations what rules apply, is it enough that 
eachpart is expanded "somewhere" even if the parts are found at 
different places. Or does the rule "expand at first occurrence apply?


I guess that in part this depends on whether we view HMAC-SHA as one 
unit or two separate parts? And how familiar we believe our readers are 
with the abbreviations.


I don't have a strong opinion on this, but would suggest that we place
HMAC-SHA in the "Abbreviations" in section 2.2 and expamnd it fully.

On 30/10/2020 10:01, Chengli (Cheng Li) wrote:

Hi WG,

Support. However, there are some encoding format changes among versions, 
hope the encoding format can be stable in the following revision ASAP.


Many thanks for the authors’ contribution!

Thanks,

Cheng

*From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *James 
Guichard

*Sent:* Thursday, October 22, 2020 8:52 PM
*To:* spring@ietf.org
*Cc:* ippm-cha...@ietf.org; spring-cha...@ietf.org
*Subject:* [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11


Dear WG:

This message starts a 3 week WG adoption call for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending 
November 12^th 2020. Please note that this document has several changes 
from v-10 that were requested by the SPRING and IPPM chairs. For this 
reason, the chairs have extended the adoption call for an additional 
week to allow the WG enough time to review these changes before deciding 
on WG adoption.


Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The 
SPRING and IPPM chairs considered those comments, and upon review of 
this version of the document, determined the following:


  * The SPRING document should describe only the procedures relevant to
SPRING with pointers to non-SPRING document/s that define any
extensions. Several extensions including*Control Code Field
Extension for TWAMP Light Messages*, *Loss Measurement Query Message
Extensions*, and *Loss Measurement Response Message Extensions *were
included in
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and
should be removed from the SPRING document.
  * The TWAMP extensions included in
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should
be described in a new document published in the IPPM WG. 

These conclusions were discussed with the authors of 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result 
of which is the publication of the following two documents:


  * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The
subject of this WG adoption call.
  * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This
document will be progressed (if determined by the WG) within the
IPPM WG.

After review of the SPRING document please indicate support (or not) for 
WG adoption to the mailing list. Please also provide comments/reasons 
for that support (or lack thereof) as silence will not be considered as 
consent.


Finally, the chairs would like to thank the authors for their efforts in 
this matter.


Thanks!

Jim, Bruno, & Joel

//


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



--

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

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

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

[Loa Andersson]

Working Grpup,

I reviewed the draft and find it a very good start for a working group
topic that is well inside the scope of what the working group needs to
be working on.

/Loa

On 15/07/2020 19:16, James Guichard wrote:

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 29^th 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



--

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

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

Re: [spring] Leadership change

[Loa Andersson]

Rob,

Thanks all the work done.

Jim and Joel,

Thanks for taking this on! Welcome"

Bruno, Jim and Joel,

Let us continue the the good cooperation between mpls and spring wg's.


/Loa


On 15/06/2020 04:25, Martin Vigoureux wrote:

WG,

Rob had decided to step down as chair some time ago. There hasn't been 
any formal communication on that so I'd like, first, to thank Rob for 
his work and dedication to the group. Thank you very much Rob.


Since that time, I have been actively looking for one (or two) person(s) 
to replace him. This has proven to be a very challenging endeavour!


But it has finally came to an end.

I am pleased to inform you that I have appointed Jim Guichard and Joel 
Halpern as co-chairs of SPRING WG, alongside Bruno.

Thank you Jim, Thank you Joel, and thank you Bruno.


Martin
as AD for SPRING

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


--

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

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

Re: [spring] Resignation request

[Loa Andersson]

Stewart, et.al.,

First, there has been some ambivalence regarding what the issue with
an AD taking this type of decission.

- there is no doubt that an AD may take this decision, module enough
  involvement in the wg and giódd understanding of the issues

- it might be discussed if the right decision were taken, from my
  point of view (personal opinion) I can live with this decision

Comment on Stewart's comment inline.


On 03/03/2020 20:32, Stewart Bryant wrote:




On 2 Mar 2020, at 21:43, Sander Steffann  wrote:

Hi,


I have no information about the situation but I do not understand why an AD 
would be declaring consensus in any case -
that is normally the responsibility of WG chairs.  see RFC 2418 section 3.3


The only active/available WG chair was a co-author of this draft.

Cheers,
Sander





As a WGC that has been in a position where the chairs had a CoI, I(we) asked 
the WG Secretary to manage the document, and that is what other WGs do. Look at 
the DetNet data plane drafts as an example. That means that the decision is 
taken at the lowest level and leaves the AD continue in the oversight role.


Yes - a much better practice. You could also appoint working group chair 
from another group as "shepherd" and explicitly delegate the task to

call consensus after the wglc.

I think that PALS did this for me once when both chairs were draft
authors.

/Loa



Anyway from the discussion on the list this probably need to go for review by 
the other two RTG ADs to check that they are happy with the decision or to 
recommend some other action.

- Stewart




--


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

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

Re: [spring] 6man w.g. last call for

[Loa Andersson]

e any 
bearing on SRv6 OAM?


[ZA] Thanks for your feedback. SRv6 OAM is in-line with OAM in IPv6 
networks, which are not of transport nature.


[LA19]This is a double reference to the same document and strictly note 
necessary The format of the second reference is also wrong and does not 
appear in the reference list.


[ZA] Fixed.

[LA20]Well, if you do you need a subsection in the IANA Consideration. 
The flag field is defined in ietf-6man-segment-routing-header, but it is 
still a draft.


As this document stands now you canít find the IANA allocations. Partly 
depending on that IANA not yet done the allocations, but also because if 
they were done there is no clear reference to the registry. SRH.Flags is 
not the name of the registry.


[ZA] Fixed.

[LA21]The notation îSRH.Flagsî is invented here, right?  
draft-ietf-6man-segment-routing-header, and the SRV6 Networking 
programming draft (which is referenced for terminology) simply talks 
about SRH or ìSRH Flagsî.


[ZA] The SRH.Flags is defined in draft-ietf-6man-segment-routing-header. 
The IANA registry for SRH.Flags is requested in 
draft-ietf-6man-segment-routing-header. This document just defined a 
flag to identify OAM packets.


[LA22]Why start with bit 2, why not 0 or 7?

[ZA] There is a long history. This O-flag flag were originally defined 
in the


https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-11.

During the LC review, it was moved to OAM draft. But the position has 
been already defined and used by the ASICs. Hence, keeping the same bit 
position.


[LA23]We are allocating a flag from a registry defined in 
draft-ietf-6man-segment- routing-header. Since this is still in IESG 
review it will not be possible progress this document until the routing 
header document is in the RFC Editors queue, and it canít become an RFC 
until the document defining the registry is also an RFC.


I think the SRH flags registry should be properly named here, "Segment 
Routing Header Flags"


[ZA] Yes, the SRH flags registry is named as "Segment Routing Header 
Flags". Please see IANA section in the new revision.


[LA24]I think the should be either OAM, Operation Administration and 
Maintenance; or O, OAM and Management.


See RFC 6291.

[ZA] Fixed.

[LA25]Note: Chapter 3 is well written and easy to understand

[ZA] Will fix it - TBD.

[LA26]Comment added after reading the entire section, the procedures and 
mechanisms described is as far as I can judge well and clearly documented.


[ZA] Thanks.

[LA27]An Extreme nit, but I would call this îPing in SRv6 Networksî

[ZA] Fixed

[LA28]I said it before ñ I donít like ìClassicî, and I donít thnk it is 
necessary or contribute significantly.


[ZA] We will think about renaming. TBD.

[LA29]I think this procedures is well and clearly documented.

[ZA] Thanks.

[LA30]As far as I can see this works.

[ZA] Thanks.

[LA31]We might want a reference.

[ZA] This should be fine as this is well know.

[LA32]At this point I start think of SRv6 as îconnection oriented.

[ZA] SRv6 enables source routing.

[LA33]I see no immediate technical problems here.

[ZA] Thanks

[LA34]I defer to the security experts on this section.

[ZA] Yes that is part of the review process.

[LA35]You need text in this section describing the allocation of the O-flag.

[ZA] Fixed.

[LA36]What are the registration procedures???

If I understand correctly we want to take one of the unused ICMPv6 Type 
Numbers and create the ìICMP Type Numbers ñ SRv6 OAM messagesî registry.


But with all due respect the text is a bit tangled.

[ZA] Fixed the text. Thanks for the good catch.

[LA37]This allocation is in itself not problematic, but the registries 
are not yet in place., weíll have to wait for the network programming 
draft to progress.


[ZA] Agreed!

Thanks

Regards … Zafar

*From: *"Zafar Ali (zali)" 
*Date: *Thursday, February 20, 2020 at 12:30 PM
*To: *Loa Andersson , Brian E Carpenter 
, Ole Troan , 6man WG 
, SPRING WG 
*Cc: *6man Chairs <6man-cha...@ietf.org>, "Zafar Ali (zali)" 

*Subject: *Re: [spring] 6man w.g. last call for 



Hi Loa,

Sorry, I could not get back to your other comments, earlier.

I am starting to look into all outstanding comments.

It will be great if you could send me copy of the word document diffs 
(privately).


But either way, your comments are quite clear.

Many Thanks

Regards … Zafar

*From: *"Zafar Ali (zali)" 
*Date: *Thursday, January 23, 2020 at 6:46 PM
*To: *Loa Andersson , Brian E Carpenter 
, Ole Troan , 6man WG 
, SPRING WG 
*Cc: *6man Chairs <6man-cha...@ietf.org>, "Zafar Ali (zali)" 

*Subject: *Re: [spring] 6man w.g. last call for 



Loa,

Many thanks.

The comments in your email has been addressed in latest version in the 
GitHub.


We are working to address the rest of your comments.

Thanks

Regards … Zafar

*From: *Loa Andersson 
*Date: *Wednesday, January 22, 2020 at 5:03 AM
*To: *"Zafar Ali (zali)" , Bri

Re: [spring] 6man w.g. last call for

[Loa Andersson]

Zafar,

Tnx - 1 down 36 to go!

Actually a bit more with the NITs output. Can you take a look at the 
long lines next, it should be easy edits.


The first two long lines are in this paragraph:

248  S01.1. IF SRH.Flags.O-flag is set and local configuration permits
249 O-flag processing THEN
250 a. Make a copy of the packet.
251 b. Send the copied packet, along with a timestamp
252to the OAM process.  ;; Ref1
253	 Ref1: An implementation SHOULD copy and record the timestamp as 
soon as
254	 possible during packet processing. Timestamp is not carried in 
the packet

255  forwarded to the next hop.

Line 253 has four characters "n as" outside the allowed 72 characters
Line 254 has the word "packet" outside the allowed 72 characters

This is inside the figure and I think that you can left shift the
enire figure, otherwise I don't see a problem with introducing line
breaks.

In figure 4:

639  > traceroute srv6 B:4:C52 via segment-list B:2:C31

641  Tracing the route to SID function B:4:C52
642   1  2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec
643  SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2)
644   2  2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec
645  SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
646   3  2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec
647  SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)

649	Figure 4 A sample output for hop-by-hop traceroute to a SID 
function


Line 649 has "tion" of "SID function" (fig numbring) outside the allowed
72 characters, again should be easy to left shif or introduce line
breaks.

The reason I want to address this first is that it is easy, but also
a show stopper.

And last, thugh I hate to add late comments - abbreviations, I have not
gone through the entire document to look for unexpanded abbreviations,
but there is at least one "NPU". Which I read as Network Processing Unit,
what confuses me is that it is not in the RFC Editors abbreviation list
at all. I think there is an action point for the wg chairs to have it
introduced, and for the authros to expand, as well as going through the
document an d make sure that everthing that should be expanded is.

/Loa

On 22/01/2020 13:15, Zafar Ali (zali) wrote:

Hi Loa,

Many thanks for your follow-up.

Based on your feedback, we have updated the version in the GitHub.

Thanks

Regards … Zafar

*From: *Loa Andersson 
*Date: *Tuesday, January 21, 2020 at 9:59 PM
*To: *"Zafar Ali (zali)" , Brian E Carpenter 
, Ole Troan , 6man WG 
, SPRING WG 

*Cc: *6man Chairs <6man-cha...@ietf.org>
*Subject: *Re: [spring] 6man w.g. last call for 



Zafar,

Thanks for addressing this. However one thing remains. The text is now:

"There MAY be additional segments preceding the END.OP/ END.OTP SID."

I don't think there is a need for requirement language in that sentence,

I read it as straightforward English:

"There may be additional segments preceding the END.OP/ END.OTP SID."

Would do very well.

Can you explain the need for requirement language?

/Loa

On 22/01/2020 01:55, Zafar Ali (zali) wrote:

Hi Brian,

Many thanks for your comments. Much appreciated.

The working copy of the new version in the repository addresses your/

Loa’s comment highlighted in your email.

https://github.com/ietf-6man/srv6-oam

Thanks

Regards … Zafar

*From: *spring mailto:spring-boun...@ietf.org>> on behalf of Brian E Carpenter

mailto:brian.e.carpen...@gmail.com>>

    *Organization: *University of Auckland

*Date: *Monday, January 20, 2020 at 2:57 PM

*To: *Loa Andersson mailto:l...@pi.nu>>, Ole Troan
mailto:otr...@employees.org>>, 6man

WG mailto:i...@ietf.org>>, SPRING WG
mailto:spring@ietf.org>>

*Cc: *6man Chairs <6man-cha...@ietf.org <mailto:6man-cha...@ietf.org>>

*Subject: *Re: [spring] 6man w.g. last call for



To be clear about one of the points in the review, MAY NOT is not

allowed by RFC2119 because it is totally ambiguous in English (since it

can mean either "must not" or "might not"). In any case the phrase "MAY

or MAY NOT" is not of any normative value. It presumably simply means

"MAY" in all cases in this draft.

Regards

  Brian

On 20-Jan-20 20:54, Loa Andersson wrote:

  WG,

  I have reviewed the entire document.

  First, I'm not an IPv6 expert.

  As far as I can see the sued on

  I have not used github, I had a couple of attempts to learn
the tools,

  but so far I have failed.

  I have instead done what I use to do, use the review tool with
Word.

  Since I sometimes have a pushback on the docx-format I s

Re: [spring] 6man w.g. last call for

[Loa Andersson]

Zafar,

Thanks for addressing this. However one thing remains. The text is now:

"There MAY be additional segments preceding the END.OP/ END.OTP SID."

I don't think there is a need for requirement language in that sentence,
I read it as straightforward English:

"There may be additional segments preceding the END.OP/ END.OTP SID."

Would do very well.

Can you explain the need for requirement language?

/Loa



On 22/01/2020 01:55, Zafar Ali (zali) wrote:

Hi Brian,

Many thanks for your comments. Much appreciated.

The working copy of the new version in the repository addresses your/ 
Loa’s comment highlighted in your email.


https://github.com/ietf-6man/srv6-oam

Thanks

Regards … Zafar

*From: *spring  on behalf of Brian E Carpenter 


*Organization: *University of Auckland
*Date: *Monday, January 20, 2020 at 2:57 PM
*To: *Loa Andersson , Ole Troan , 6man 
WG , SPRING WG 

*Cc: *6man Chairs <6man-cha...@ietf.org>
*Subject: *Re: [spring] 6man w.g. last call for 



To be clear about one of the points in the review, MAY NOT is not 
allowed by RFC2119 because it is totally ambiguous in English (since it 
can mean either "must not" or "might not"). In any case the phrase "MAY 
or MAY NOT" is not of any normative value. It presumably simply means 
"MAY" in all cases in this draft.


Regards

    Brian

On 20-Jan-20 20:54, Loa Andersson wrote:

WG,

I have reviewed the entire document.

First, I'm not an IPv6 expert.

As far as I can see the sued on

I have not used github, I had a couple of attempts to learn the tools,

but so far I have failed.

I have instead done what I use to do, use the review tool with Word.

Since I sometimes have a pushback on the docx-format I save the result

as a .txt-file. Drawback is that all comment show up as refrences to a

list at the end of the document. But you can't get everything.

/Loa

PS gives this output for this draft; it is quite a lot and in itself are

so much that it is worth sending it bck to the authors and asking them

to fix it. Was the noits tool checked at all before starting the wglc?

idnits 2.16.02

/tmp/draft-ietf-6man-spring-srv6-oam-03.txt:

 Checking boilerplate required by RFC 5378 and the IETF Trust (see

https://trustee.ietf.org/license-info):



    No issues found here.

 Checking nits according to

https://www.ietf.org/id-info/1id-guidelines.txt:



    No issues found here.

 Checking nits according to https://www.ietf.org/id-info/checklist :



 ** There are 3 instances of too long lines in the document, the

longest one

    being 6 characters in excess of 72.

 == There are 5 instances of lines with non-RFC3849-compliant IPv6

addresses

    in the document.  If these are example addresses, they
should be

changed.

 Miscellaneous warnings:



 == The copyright year in the IETF Trust and authors Copyright Line

does not

    match the current year

 -- The exact meaning of the all-uppercase expression 'MAY NOT'
is not

    defined in RFC 2119.  If it is intended as a requirements

expression, it

    should be rewritten using one of the combinations defined in
RFC 2119;

    otherwise it should not be all-uppercase.

 == The expression 'MAY NOT', while looking like RFC 2119
requirements

text,

    is not defined in RFC 2119, and should not be used.  Consider

using 'MUST

    NOT' instead (if that is what you mean).

    Found 'MAY NOT' in this paragraph:

    To perform ICMPv6 ping to a target SID an echo request
message is

    generated by the initiator with the END.OP or END.OTP SID in the

    segment-list of the SRH immediately preceding the target SID.

There MAY

    or MAY NOT be additional segments preceding the END.OP/
END.OTP SID.

 == The expression 'MAY NOT', while looking like RFC 2119
requirements

text,

    is not defined in RFC 2119, and should not be used.  Consider

using 'MUST

    NOT' instead (if that is what you mean).

    Found 'MAY NOT' in this paragraph:

    To traceroute a target SID a probe message is generated by the

    initiator with the END.OP or END.OTP SID in the segment-list of

the SRH

    immediately preceding the target SID.  There MAY or MAY NOT be

additional

    segments preceding the END.OP/ END.OTP 

Re: [spring] 6man w.g. last call for

[Loa Andersson]

Bob,


Here is the docx-file, it is not exactly the same version as I used to
create the txt-file, since I continued to look at the figure for the
reference topology, and in that process I also corrected a spelling
erros and cleared up the text for some comments.

The only real change is that I have added an alternative to the figure
(note: no problems with the topology itself) for the reference topology
at the end of the docx file.

/Loa

On 20/01/2020 19:12, Bob Hinden wrote:

Loa,

Thanks for doing the review.  I think it may be worthwhile to also send out the 
.docx file in addition to the text version.

Bob



On Jan 19, 2020, at 11:54 PM, Loa Andersson  wrote:

WG,

I have reviewed the entire document.

First, I'm not an IPv6 expert.

As far as I can see the sued on

I have not used github, I had a couple of attempts to learn the tools,
but so far I have failed.

I have instead done what I use to do, use the review tool with Word.

Since I sometimes have a pushback on the docx-format I save the result
as a .txt-file. Drawback is that all comment show up as refrences to a
list at the end of the document. But you can't get everything.


/Loa

PS gives this output for this draft; it is quite a lot and in itself are
so much that it is worth sending it bck to the authors and asking them
to fix it. Was the noits tool checked at all before starting the wglc?

idnits 2.16.02

/tmp/draft-ietf-6man-spring-srv6-oam-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):


 No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:


 No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :


  ** There are 3 instances of too long lines in the document, the longest one
 being 6 characters in excess of 72.

  == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses
 in the document.  If these are example addresses, they should be changed.


  Miscellaneous warnings:


  == The copyright year in the IETF Trust and authors Copyright Line does not
 match the current year

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
 defined in RFC 2119.  If it is intended as a requirements expression, it
 should be rewritten using one of the combinations defined in RFC 2119;
 otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
 is not defined in RFC 2119, and should not be used.  Consider using 'MUST
 NOT' instead (if that is what you mean).

 Found 'MAY NOT' in this paragraph:

 To perform ICMPv6 ping to a target SID an echo request message is
 generated by the initiator with the END.OP or END.OTP SID in the
 segment-list of the SRH immediately preceding the target SID. There MAY
 or MAY NOT be additional segments preceding the END.OP/ END.OTP SID.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
 is not defined in RFC 2119, and should not be used.  Consider using 'MUST
 NOT' instead (if that is what you mean).

 Found 'MAY NOT' in this paragraph:

 To traceroute a target SID a probe message is generated by the
 initiator with the END.OP or END.OTP SID in the segment-list of the SRH
 immediately preceding the target SID.  There MAY or MAY NOT be additional
 segments preceding the END.OP/ END.OTP SID.

  -- The document date (December 18, 2019) is 32 days in the past.  Is this
 intentional?


  Checking references for intended status: Proposed Standard


 (See RFCs 3967 and 4897 for information about using normative references
 to lower-maturity documents in RFCs)

  == Missing Reference: 'SL' is mentioned on line 190, but not defined

  -- Looks like a reference, but probably isn't: '2' on line 191

  -- Looks like a reference, but probably isn't: '1' on line 191

  -- Looks like a reference, but probably isn't: '0' on line 192

  == Missing Reference: 'RFC7011' is mentioned on line 230, but not defined

  == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line
 241, but not defined

  == Missing Reference: 'RFC792' is mentioned on line 701, but not defined

  == Missing Reference: 'RFC 8403' is mentioned on line 660, but not defined

  == Unused Reference: 'RFC0792' is defined on line 823, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8403' is defined on line 843, but no explicit
 reference was found in the text

Re: [spring] 6man w.g. last call for

[Loa Andersson]

. Voyer, M. Chen
   Filename : draft-ietf-6man-spring-srv6-oam-02
   Pages: 23
   Date : 2019-11-20
  
 https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/


as a Proposed Standard.

Substantive comments and statements of support for publishing this document 
should be directed to the mailing list.
Editorial suggestions can be sent to the author. This last call will end on the 
18th of December 2019.

To improve document quality and ensure that bugs are caught as early as 
possible, we would require at least
two reviewers to do a complete review of the document.  Please let the chairs 
know if you are willing to be a reviewer.

The last call will be forwarded to the spring working group, with discussion 
directed to the ipv6 list.

Thanks,
Bob & Ole, 6man co-chairs



IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6




--


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




6man  Z. Ali
Internet-Draft   C. Filsfils
Intended status: Standards Track   Cisco Systems
Expires: June 20, 2020 S. Matsushima
Softbank
D. Voyer
 Bell Canada
 M. Chen
  Huawei
   December 18, 2019


  Operations, Administration, and Maintenance (OAM) in Segment Routing
  Networks with IPv6 Data plane (SRv6)
   draft-ietf-6man-spring-srv6-oam-03

Abstract[LA1]

   This document defines building blocks for Operations, Administration,
   and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane[LA2]
   (SRv6).  The document also describes some[LA3] SRv6 OAM mechanisms.

Requirements Language[LA4]

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].[LA5]

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 20, 2020.







Ali, et al.   Expires June 20, 2020 [Page 1]


Internet-Draft  SRv6 OAM   December 2019


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
 2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
 2.2.  Terminology and Reference Topology  . . . . . . . . . . .   3
   3.  OAM Building Blocks . . . . . . . . . . . . . . . . . . . . .   5
 3.1.  O-flag in Segment Routing Header  . . . . . . . . . . . .   5
   3.1.1.  O-flag Processing . . . . . . . . . . . . . . . . . .   6
 3.2.  OAM Segments  . . . . . . . . . . . . . . . . . . . . . .   6
 3.3.  End.OP: OAM Endpoint with Punt  . . . . . 

Re: [spring] What needs to be renamed -- Re: draft-bonica-spring-srv6-plus: Renaming

[Loa Andersson]

Ron,

I thought I made a canonical search, but must have picked up an old
version.

Sorry.

/Loa

On 19/11/2019 00:26, Ron Bonica wrote:

Hi Loa,

I just did a scan of the latest document version (i.e., 
draft-bonica-spring-srv6-plus-06).

The title is "Segment Routing Mapped To IPv6 (SRm6)".

The string "SRv6+" three times. These are:

- Once in a Section Header (i.e., "Differences Between SRv6 and SRv6+"). This 
was an oversight. When I did a global search and replace, XMLMind didn't catch section 
headers.

- Once in the table of contents. This was a consequence of the first oversight.

- Once in a reference to another draft that has not been updated yet.


Ron



Juniper Business Use Only

-----Original Message-
From: Loa Andersson 
Sent: Monday, November 18, 2019 12:55 AM
To: Ron Bonica ; Darren Dukes (ddukes) 

Cc: draft-bonica-spring-srv6-p...@ietf.org; SPRING WG 
Subject: What needs to be renamed -- Re: [spring] 
draft-bonica-spring-srv6-plus: Renaming

Ron,

I don't understand why changing the filename should be an issue, isn't it the 
title of the document that needs to be changed?

And the approximately 100 time the term "SRv6+" is used in the document.

/Loa

On 18/11/2019 12:05, Ron Bonica wrote:

Darren,

No problem. We will change the filename next time we update the document.

  Ron


Juniper Business Use Only

-Original Message-
From: Darren Dukes (ddukes) 
Sent: Sunday, November 17, 2019 8:36 PM
To: Ron Bonica 
Cc: SPRING WG ;
draft-bonica-spring-srv6-p...@ietf.org
Subject: draft-bonica-spring-srv6-plus: Renaming

Hi Ron and SRm6 authors.

The use of the name “SRv6+” is still causing confusion amongst the community, 
and even during presentations by the authors of this series of drafts (eg 
NANOG).
It needs to be changed in the doc names and removed from further presentations.

This was promised in this thread.
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
ng/DNfkjnGMHbmJx2dL8KY_pseFyzM__;!8WoA6RjC81c!TO6Y432l65MppFAzk6ouvlJP
d2AC_TMHeOXuTOvwpoCfdOuSDYGLoyVLj0Bii58r$

Thanks for closing this.
Darren
___
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
ng__;!8WoA6RjC81c!XmkrambL1q1Q66rN0XCqbB5QUVLauLhIwWplEet0gRvXi2OTPrYJ
CQRh1oUmg7hQ$





--


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

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

[spring] What needs to be renamed -- Re: draft-bonica-spring-srv6-plus: Renaming

[Loa Andersson]

Ron,

I don't understand why changing the filename should be an issue, isn't
it the title of the document that needs to be changed?

And the approximately 100 time the term "SRv6+" is used in the document.

/Loa

On 18/11/2019 12:05, Ron Bonica wrote:

Darren,

No problem. We will change the filename next time we update the document.

 Ron


Juniper Business Use Only

-Original Message-
From: Darren Dukes (ddukes) 
Sent: Sunday, November 17, 2019 8:36 PM
To: Ron Bonica 
Cc: SPRING WG ; draft-bonica-spring-srv6-p...@ietf.org
Subject: draft-bonica-spring-srv6-plus: Renaming

Hi Ron and SRm6 authors.

The use of the name “SRv6+” is still causing confusion amongst the community, 
and even during presentations by the authors of this series of drafts (eg 
NANOG).
It needs to be changed in the doc names and removed from further presentations.

This was promised in this thread.
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/DNfkjnGMHbmJx2dL8KY_pseFyzM__;!8WoA6RjC81c!TO6Y432l65MppFAzk6ouvlJPd2AC_TMHeOXuTOvwpoCfdOuSDYGLoyVLj0Bii58r$

Thanks for closing this.
   Darren
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



--


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

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

Re: [spring] Request for WG adoption of draft-dong-spring-sr-for-enhanced-vpn-05

[Loa Andersson]

WG,

I reviewed this document before the last version, my comments have been
addressed and I think this is ready for adoption as a working grouo
document.

/Loa

On 2019-10-21 12:16, li zhenqiang wrote:

Hello all and chairs,

I support the adoption poll as a co-author. I believe the doc is mature 
enough to be a wg item.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Dongjie (Jimmy) <mailto:jie.d...@huawei.com>
*Date:* 2019-10-21 13:21
*To:* 'SPRING WG List' <mailto:spring@ietf.org>
*CC:* spring-cha...@ietf.org <mailto:spring-cha...@ietf.org>
*Subject:* [spring] Request for WG adoption of
draft-dong-spring-sr-for-enhanced-vpn-05
Dear WG and Chairs,
A new revision of draft-dong-spring-sr-for-enhanced-vpn has been
uploaded to resolve some recently received comments. This document
describes the Segment Routing based mechanism to provide enhanced
VPN, which aligns with the enhanced VPN (VPN)+ framework document in
TEAS WG. The mechanism could be used to enable transport network
slicing for 5G.
The major changes compared to the -04 version are:
   1. Update the draft template.
   2. Add reference to the definition of network slicing in 3GPP
TS23.501 and the definition of transport network slicing in
draft-ietf-teas-enhanced-vpn-03 respectively.
   3. Editorial changes in several sections to clarify and improve
the readability.
   4. Change some coauthors' affiliation and mail address.
This update shows that the major content of this draft has become
stable and solid, thus the authors would like to request the WG to
consider the adoption of this document.
Comments are always welcome. Thanks.
Best regards,
Jie
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, October 16, 2019 3:28 PM
To: Takuya Miyasaka ; Zhenqiang Li
; Fengwei Qin
; Stewart Bryant
; Yongqing Zhu ;
Dongjie (Jimmy) 
Subject: New Version Notification for
draft-dong-spring-sr-for-enhanced-vpn-05.txt
A new version of I-D, draft-dong-spring-sr-for-enhanced-vpn-05.txt
has been successfully submitted by Jie Dong and posted to the IETF
repository.
Name: draft-dong-spring-sr-for-enhanced-vpn
Revision: 05
Title: Segment Routing for Enhanced VPN Service
Document date: 2019-10-16
Group: Individual Submission
Pages: 20
URL:   
https://www.ietf.org/internet-drafts/draft-dong-spring-sr-for-enhanced-vpn-05.txt
Status:
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
Htmlized:  
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-05
Htmlized:  
https://datatracker.ietf..org/doc/html/draft-dong-spring-sr-for-enhanced-vpn
Diff:  
https://www.ietf.org/rfcdiff?url2=draft-dong-spring-sr-for-enhanced-vpn-05

Abstract:
    Enhanced VPN (VPN+) is an enhancement to VPN services to enable
it to
    support the needs of new applications, particularly applications
that
    are associated with 5G services.  These applications require better
    isolation from both control and data plane's perspective and have
    more stringent performance requirements than can be provided with
    overlay VPNs.  The characteristics of an enhanced VPN as
perceived by
    its tenant needs to be comparable to those of a dedicated private
    network.  This requires tight integration between the overlay
VPN and
    the underlay network topology and resources in a scalable
manner.  An
    enhanced VPN may form the underpinning of 5G network slicing, but
    will also be of use in its own right.  This document describes
how to
    use segment routing based mechanisms to provide the enhanced VPN
    service with the required network topology and resources.  The
    overall mechanism of providing segment routing based enhanced VPN
    service is also described.  The proposed mechanism is applicable to
    both segment routing with MPLS data plane (SR-MPLS) and segment
    routing with IPv6 data plane (SRv6).
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


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



--


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

___
s

Re: [spring] draft-ali-6man-spring-srv6-oam-00

[Loa Andersson]

Robert,

I think that I might have been unclear,

- I understand that RFC 8200 does not use normative language, nor MUST
  neither RECOMMENDED, just normal English "recommended". I also
  understand that this is fine for the situation before draft-ali-6man-
  spring-srv6-oam, we recommend an order for the extension headers, but
  nothing bad happens if that order is not strictly followed.

- What Rajesh comment seems to imply is that it will fore draft-
  ali-6man-spring-srv6-oam as long recommended the ordering is kept.

- what I was wondering was if it is possible to demonstrate that it
  will not work if the recommended ordering is not kept.

- and a follow up to this, if it is possible to demonstrate that it will
  not work if the recommended is not kept, should we in this case mnake
  the now "recommended" order "MANDATORY"?

/Loa

On 2019-05-23 16:31, Robert Raszuk wrote:

Hi Loa,

On Thu, May 23, 2019 at 5:42 AM Loa Andersson <mailto:l...@pi.nu>> wrote:


Rajesh,

It seems to me that "it is recommended" indicate that the ordering is
optional/OPTIONAL. 



Indeed. There is no MUST there. That is precisely what section 4.1 of 
RFC8200 says:



  4.1 <https://tools.ietf.org/html/rfc8200#section-4.1>. Extension
  Header Order



  When more than one extension header is used in the same packet, it is

*  recommended *that those headers appear in the following order:

Does this document (or your comment) create a
MANDATORY ordering of EH's??


If by "this document" you mean draft-ali-6man-spring-srv6-oam then no - 
I do not see any text there which would even attempt to enforce any EH 
ordering.


As far as creating MANDATORY ordering "by a comment" that must be pretty 
new extension to the IETF process :)


Best,
R..


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



--


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

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

Re: [spring] draft-ali-6man-spring-srv6-oam-00

[Loa Andersson]

must be A:5:: ?

> ping A:5:: via segment-list B:2:C31, B:4:C52

Sending 5, 100-byte ICMP Echos to *B5::,* timeout is 2 seconds:

!

> traceroute A:5:: via segment-list B:2:C31, B:4:C52

Tracing the route to *B5::*

Thanks

Rajesh

Juniper Internal


IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA=jrfq1dYsfk8_fBqqNNS-gdRsYxNXOt7r52G3GHN0iiQ=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OYo=>


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

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA=bA6bNX7XD3BHTzukhcoIS-aqZi6dWcnVVdTfYB1goG8=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuNWxM=>


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



--


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

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

Re: [spring] Updates to draft-gandhi-spring-ioam-sr-mpls

[Loa Andersson]

Rakesh,

A couple of thoughts and questions.

- is it necessary to have three different ways to establish the
  IOAM Indicator Label?
- if it is necessary to use a Special Purpose Label, could you use
  a eSPL instead of a bSPL (for terminology see draft-andersson-mpls-
  spl-terminology)?
- will the label serving as as IOAM Indicator always be a the bottom
  of the stack and have the s-bit set?
- allocating SPL's is a decision that I would want the MPLS working
  group to take, this could be done in one of two ways, either we
  progress in the mpls wg or you split out the IANA allocation in a
  separate document and progress that in the mpls wg.

/Loa

On 2019-05-22 06:49, Rakesh Gandhi (rgandhi) wrote:

Hi WG,

We have published an update to the following draft:

https://datatracker.ietf.org/doc/draft-gandhi-spring-ioam-sr-mpls/

/draft-gandhi-spring-ioam-sr-mpls/ defines how IOAM data fields are 
transported with SR-MPLS encapsulation. The draft has been updated as 
following://


 1. Add different methods of IOAM Indicator Label in Section 4.1.
 2. Add Hashing function in Section 4.2.
 3. Add Node capability in Section 4.3.
 4. Cleanup/editorial changes

Welcome your review comments and suggestions.

Thanks,

Rakesh (on behalf of co-authors and contributors)


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



--


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

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

Re: [spring] 答复: SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp

[Loa Andersson]

Quan,


I think you are right that this discussion will be of interest
for the SPRING and MPLS working group.

I have copied the working group mailing lists.

On 2019-04-10 09:47, xiong.q...@zte.com.cn wrote:


Hi Loa,


Thanks for your review and inspired comment! It is very important and 
much appreciated.



Refer to your question, we proposed the terminology of the "SR-MPLS-TP" 
in the following use case draft.


<https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/>https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/ 




We plan to work on the definition and scope of SR-MPLS-TP and start 
discussion in MPLS and SPRING working group next week.


Welcome to review and discuss about that draft and provide suggestions 
for SR-MPLS-TP!



Best Regards,

Quan



原始邮件
*发件人：*LoaAndersson 
*收件人：*p...@ietf.org 
;draft-xiong-pce-pcep-extension-sr...@ietf.org 
;

*日 期 ：*2019年04月10日 03:55
*主 题 ：**SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp*
Authors, Working Group,

MPLS-TP is defined as a network that:

    "It MUST be possible to operate and configure the MPLS-TP data
 plane without any IP forwarding capability in the MPLS-TP data
 plane. (RFC 5654, section 2.3, requirement 36.)"

 ...

   "It MUST be possible to provide protection for the MPLS-TP data
    plane without any IP forwarding capability in the MPLS-TP data
    plane. (RFC 5654, section 2.5.1.1, requirement 63.)"

In fact most MPLS-TP networks are deployed without IP in the data
plane.

SR-MPLS on the other hand is a technology that is defined to USE
IGPs to distribute MPLS-labels, and thus requires IP in the data
plane.

PCEP also runs over TCP/IP.

The draft does not discuss this. I think this is needed, do you
have plans to do so?

/Loa
--


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




--


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

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

[spring] Resend: Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

[Loa Andersson]

Working Group,

Bruno pointed out that I by mistake send this mail uni-directionally to 
him only. It is clearly intended for the working group.


/Loa


 Forwarded Message 
Subject: Re: [spring] Working Group Adoption Call for 
draft-filsfils-spring-srv6-network-programming

Date: Thu, 14 Mar 2019 10:26:44 +0800
From: Loa Andersson 
To: bruno.decra...@orange.com

Working Group,

I support the adoption of this draft as a working group document.

I made some comments on the IANA section. I don't think that these
comments needs to be resolved before adopting the draft.

https://mailarchive.ietf.org/arch/msg/spring/JJPtc8xzSlB6Qb5wKdxS7pzTry8

However, I got a response from Pablo that since there are
implementations/deployments they want to do early allocations. I think
that my comments need to be addressed prior to doing these early
allocations.

/Loa

On 2019-03-14 02:49, bruno.decra...@orange.com wrote:

Hi SPRING WG,

This email initiates a three week call for working group adoption for 
draft-filsfils-spring-srv6-network-programming. (Three weeks to account 
for the IETF week)


Please indicate your support, comments, or objection, for adopting this 
draft as a working group item by April, 3^rd , 2019 (aka 2019-04-03)


We are particularly interested in hearing from working group members 
that are not co-authors of this draft.


We are also looking for volunteers who would be ready to perform a 
technical review of this work at some later stage, such as before or 
during WG the last call.


In parallel to this adoption call, I will send an IPR call for this 
document. We will need all authors and contributors to confirm their IPR 
position on this document.


There is currently 1 IPR filled (2)

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

(2)https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming=draft

Thank  you,

--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



--


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

--


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

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

Re: [spring] draft-filsfils-spring-srv6-network-programming

[Loa Andersson]

g-boun...@ietf.org] *On Behalf Of *Pablo Camarillo 
(pcamaril)
*Sent:* Thursday, February 14, 2019 4:56 PM
*To:* spring@ietf.org
*Subject:* [spring] draft-filsfils-spring-srv6-network-programming
Dear Spring,
We have submitted a new revision of 
draft-filsfils-spring-srv6-network-programming. There are several minor updates 
to the document, mainly addressing ICMP and having better alignment with SRH 
draft. Also, based on WG feedback, we have split the document moving the 
illustrations into a new informational draft.
As always, any feedback or question is more than welcome.
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-illustration/
We believe that the content of both drafts is mature and has been stable since 
the first revision in March 2017. We are tracking several opensource and vendor 
proprietary implementations. Some of these have actually participated in a 
public interop more than a year ago.
For these reasons we believe that both documents are ready to progress and be 
adopted by the working group.
Thanks,
Pablo (on behalf of authors)


___
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



--


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

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

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

[Loa Andersson]

Greg,

We are close, though I hope the rules are that GAL is bottom of stack,
and that a packet with a GACh does not carry user payload.

I should have said that "if you want a GACg for the

I don't understand why we need a "new" SR tunnel, the GAL/GACh can
ride with the GAL as bottom of stack with the label stack for
Sub-path(B->C), right? If you put it on "another" tunnel, how do
you guarantee fate sharing?

/Loa

/Loa

On 2019-02-23 11:55, Greg Mirsky wrote:

Hi Loa,
I think it will be similar to SPME and we'll need to have another 
SR-tunnel B-C with its own Path segment allocated by node C. But GAL 
will still be BoS.


Regards,
Greg.

On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson <mailto:l...@pi.nu>> wrote:


Rakesh, authors,

I have not been thinking about this too much. But if you look at fig 2
of draft-cheng-spring-mpls-path-segment, and you need a GACh between
A and D, I'd say that the GAL will be at the bottom of stack.

What if you need the CACh for the sub-path B to C, where will the GAL
go?

/Loa



On 2019-02-23 09:25, Rakesh Gandhi wrote:
 > Hi Greg,
 >
 > I am not sure if the question has been answered. I would think
GAL is at
 > the bottom of the label stack.
 >
 > Thanks,
 > Rakesh
 >
 >
 > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky
mailto:gregimir...@gmail.com>
 > <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> wrote:
 >
 >     Hi Weiqiang Cheng,
 >     thank you for your expedient response to my questions. The
document
 >     states that one of the use cases for the Path segment is to
be used
 >     as a performance, packet loss and/or delay, measurement session
 >     identifier. I think that RFC 6374 is the most suitable for PM
OAM in
 >     SR-MPLS environment. Of course, the type of the
encapsulated message
 >     can be identified using the destination UDP port number with
IP/UDP
 >     encapsulation. But another option is to use G-ACh encapsulation.
 >     That would require the use of GAL. And that is how I've
arrived at
 >     my original question (I should have explained it better, my
apologies):
 >
 >         How the Path segment and GAL are placed relative to each
other
 >         in the SR-MPLS label stack?
 >
 >     Regards,
 >     Greg
 >
 >     On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
 >     mailto:chengweiqi...@chinamobile.com>
 >     <mailto:chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>>> wrote:
 >
 >         Hi Greg,
 >
 >         Thanks a lot for your comments.
 >
 >         My comments are in-line.
 >
 >         __ __
 >
 >         B.R.
 >
 >         Weiqiang Cheng
 >
 >         __ __
 >
 >         *发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
<mailto:gregimir...@gmail.com>
 >         <mailto:gregimir...@gmail.com
<mailto:gregimir...@gmail.com>>]
 >         *发送时间:*2019年2月15日3:37
 >         *收件人:*Alexander Vainshtein
 >         *抄送:*spring@ietf.org <mailto:spring@ietf.org>
<mailto:spring@ietf.org <mailto:spring@ietf.org>>; Stewart Bryant;
 > draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>
 >         <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>>;
 > m...@ietf.org <mailto:m...@ietf.org> <mailto:m...@ietf.org
<mailto:m...@ietf.org>>; Loa Andersson
 >         *主题:*Re: [spring] to progress
 >         draft-cheng-spring-mpls-path-segment
 >
 >         __ __
 >
 >         Dear All,
 >
 >         I concur with all what has been said in support of the
adoption
 >         of this draft by SPRING WG. The document is well-written,
 >         addresses the real problem in SR-MPLS, and the proposed
solution
 >         is technically viable.
 >
 >         My comments and questions are entirely for further
discussion:
 >
 >           * would the draft be expanded to demonstrate how "the Path
 >             Segment may be used to identify an SR-MPLS Policy, its
 >             Candidate-Path (CP) or a SID List (SL)"?
 >
 >         [Weiqiang] Yes, It is necessary and we will add some text to
 >         demonstrate this in the future version. 
 >
 >           * as many use cases for the Pa

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

[Loa Andersson]

Rakesh, authors,

I have not been thinking about this too much. But if you look at fig 2
of draft-cheng-spring-mpls-path-segment, and you need a GACh between
A and D, I'd say that the GAL will be at the bottom of stack.

What if you need the CACh for the sub-path B to C, where will the GAL
go?

/Loa



On 2019-02-23 09:25, Rakesh Gandhi wrote:

Hi Greg,

I am not sure if the question has been answered. I would think GAL is at 
the bottom of the label stack.


Thanks,
Rakesh


On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky <mailto:gregimir...@gmail.com>> wrote:


Hi Weiqiang Cheng,
thank you for your expedient response to my questions. The document
states that one of the use cases for the Path segment is to be used
as a performance, packet loss and/or delay, measurement session
identifier. I think that RFC 6374 is the most suitable for PM OAM in
SR-MPLS environment. Of course, the type of the encapsulated message
can be identified using the destination UDP port number with IP/UDP
encapsulation. But another option is to use G-ACh encapsulation.
That would require the use of GAL. And that is how I've arrived at
my original question (I should have explained it better, my apologies):

How the Path segment and GAL are placed relative to each other
in the SR-MPLS label stack?

Regards,
Greg

On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
mailto:chengweiqi...@chinamobile.com>> wrote:

Hi Greg,

Thanks a lot for your comments.

My comments are in-line.

__ __

B.R.

Weiqiang Cheng

__ __

*发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
<mailto:gregimir...@gmail.com>]
*发送时间:*2019年2月15日3:37
*收件人:*Alexander Vainshtein
*抄送:*spring@ietf.org <mailto:spring@ietf.org>; Stewart Bryant;
draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>;
m...@ietf.org <mailto:m...@ietf.org>; Loa Andersson
*主题:*Re: [spring] to progress
draft-cheng-spring-mpls-path-segment

__ __

Dear All,

I concur with all what has been said in support of the adoption
of this draft by SPRING WG. The document is well-written,
addresses the real problem in SR-MPLS, and the proposed solution
is technically viable.

My comments and questions are entirely for further discussion:

  * would the draft be expanded to demonstrate how "the Path
Segment may be used to identify an SR-MPLS Policy, its
Candidate-Path (CP) or a SID List (SL)"?

[Weiqiang] Yes, It is necessary and we will add some text to
demonstrate this in the future version. 

  * as many use cases for the Path Segment are related to OAM
operations, it would be helpful to expand on the use of GAL
and the Path Segment.

[Weiqiang] It is always helpful to have more use cases. However,
The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is
used for OAM packets only while the Path segment is used for
data packets for the each traffic flow. It is a little bit
different. 

Regards,

Greg

__ __

On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein
mailto:alexander.vainsht...@ecitele.com>> wrote:

+1.



I have been following this draft from its -00 revision. The
current revision has resolved most of the issues I (and
others) have been raised (e.g., elimination of excessive
options).



 From my POV, in its current state the draft meets two basic
requirements for the WG adoption:

1.It addresses a real and relevant problem, namely the MPLS
Flow Identification problem discussed in general in RFC 8372
<https://tools.ietf.org/html/rfc8372> and scoped to SR-MPLS
LSPs in this draft. Specifics of SR-MPLS include the need to
provide end-to-end liveness check that is one of the
requirements explicitly specified in Section 2 of RFC 8355
<https://tools.ietf.org/html/rfc8355>. 

2.It provides a reasonable (from my POV) approach to
  solution of this problem.



I also concur with Stewart’s comment about strong similarity
between the approach taken in this draft for SR-MPLS and
generic work in progress on synonymous flow labels
<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>
that has been already adopted as a MPLS WG item.  To me this
is yet another indication t

[spring] to progress draft-cheng-spring-mpls-path-segment

[Loa Andersson]

Working Group,

I have reviewed draft-cheng-spring-mpls-path-segment and as far
as I can see, it is ready for wg adoption.

There were some comments in Bangkok, but due to the many collisions
between working groups at that meeting I couldn't attend the SPRING
f2f.

The minutes are not clear, but as far as I understand, there is
nothing that can't be resolved in the wg process.

/Loa
--


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

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

Re: [spring] [RTG-DIR] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

[Loa Andersson]

Shraddha,

My earlier mail bounced from the spring wg mailing list.

I agree that the new section would be useful.

/Loa

On 2018-11-20 00:01, Przemyslaw Krol wrote:

Hi Shraddha

I think this would be very helpful.

pk

On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde > wrote:


Hi all,

__ __

I am preparing the shepherd write-up and noticed that the topic in
below e-mail thread is an

Open item. My personal opinion is to add a new section to this draft
to address below cases

>  more than one node advertising the same IPv4/6 PREFIX and both
have the same prefix-SID value with "N" flag

>  where an anycast prefix is advertised with a prefix-SID sub-TLV by
some (but not all) of the nodes that advertise that prefix.

__ __

This draft is addressing incoming label collision and resulting
behavior and also describes other aspects like different SIDs for
same prefix so it seems reasonable to add above two cases to this
draft.

WG members, if you have an opinion, pls respond on the list.

__ __

Rgds

Shraddha

*From:*Alexander Vainshtein mailto:alexander.vainsht...@ecitele.com>>
*Sent:* Sunday, November 4, 2018 9:37 PM
*To:* Ahmed Bashandy mailto:abashandy.i...@gmail.com>>
*Cc:* rtg-...@ietf.org ; 'm...@ietf.org
' mailto:m...@ietf.org>>;
'adr...@olddog.co.uk '
mailto:adr...@olddog.co.uk>>; Jonathan
Hardwick (jonathan.hardw...@metaswitch.com
)
mailto:jonathan.hardw...@metaswitch.com>>; spring@ietf.org
; spring-cha...@ietf.org
;
draft-ietf-spring-segment-routing-mpls.auth...@ietf..org
;
Shraddha Hegde mailto:shrad...@juniper.net>>
*Subject:* RE: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13

__ __

Ahmed,

Apologies for a delayed response.

I fully agree that advertising the same prefix SID as the Node SID
by two different nodes in the SR domain is “a clear violation of the
SR architecture RFC (8402)”.

But I do not think that the SR-MPLS draft can silently ignore this
violation just because it “is not an incoming label collision”. 

The same applies to the controversy in advertising at the same
prefix as Anycast by some nodes but not as Anycast (or even as a
Node SID) by some other nodes. 

Your reference to these being just control plane issues and
therefore not related to SR-MPLS is not valid - because the drafts
dealing with the SR control plane to which you refer in this draft
are strictly MPLS-oriented: they define how to advertise */SID
labels/* or */indices/* that are translated into */SID labels/*, and
neither of these mechanisms is relevant fore SRV6 IMHO. (I do not
have to remind you that a draft that defines SRV6 extensions for
ISIS

exists,
and deals with other issues).

My 2c,

Sasha

__ __

Office: +972-39266302

Cell:  +972-549266302

Email: alexander.vainsht...@ecitele.com


__ __

*From:*Ahmed Bashandy [mailto:abashandy.i...@gmail.com]
*Sent:* Sunday, October 28, 2018 1:01 AM
*To:* Shraddha Hegde mailto:shrad...@juniper.net>>; Alexander Vainshtein
mailto:alexander.vainsht...@ecitele.com>>
*Cc:* rtg-...@ietf.org ; 'm...@ietf.org
' mailto:m...@ietf.org>>;
'adr...@olddog.co.uk '
mailto:adr...@olddog.co.uk>>; Jonathan
Hardwick (jonathan.hardw...@metaswitch.com
)
mailto:jonathan.hardw...@metaswitch.com>>; spring@ietf.org
; spring-cha...@ietf.org
;
draft-ietf-spring-segment-routing-mpls.auth...@ietf.org

*Subject:* Re: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13

__ __

Thanks for the comments

While it is a clear violation of the SR architecture RFC (8402),
more than one node advertising the same IPv4/6 PREFIX and both have
the same prefix-SID value with "N" flag is not an incoming label
collision because the label is associated with the same FEC, which
is the 

[spring] Working Group for draft-iqbal-spring-mpls-ping-algo

[Loa Andersson]

Working Groups,

The SPRING and MPLS chairs have agreed that draft-iqbal-spring-
mpls-ping-algo should be progressed in SPRING.

The chairs agree that work on this draft require (some level of)
awareness of work in the MPLS wg, we also agree that the MPLS wg
should be copied on e.g. working group adoption polls and wglc.

/Loa
for the SPRING and MPLS wg chairs
--


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

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

Re: [spring] Updating the SPRING WG Charter

[Loa Andersson]

Rob,

Two things

- do we have an available current state of the charter-to-bu-updated
  text.
- inline plz

On 2018-06-04 18:44, Rob Shakir wrote:

Michael,

Thanks for the comment.

On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:


It would be helpful, while updating the charter, to state whether
multicast in SR is in/out of scope in order to know which wg to take
our future work.


I think this is impractical. 


Yes, I agree that it is impractical have "everything" out of scope
listed. However for things being brought up for discussion we need
clear decisions/consensus documented on the mailing list.

Does your statement mean that "multicast in SR" is out of scope for
SPRING?

/Loa


If we state everything that is in or out of
scope, we'll end up with a laundry list. The aim of the charter is to 
define clearly the work that the WG should focus on. It does not mean 
that we can never host discussion of individual drafts if they are 
relevant. If there are requirements, we can always recharter if 
something new becomes the highest priority for the industry w.r.t SR.


Kind regards,
r.


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



--


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

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

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

[Loa Andersson]

Working Group,

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

Part of this preparation is to do an IPR poll.

This mail is to start the IPR poll.

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

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

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

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

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

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


/Loa
 mpls wg co-chair
--


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

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

Re: [spring] About draft-ali-spring-srv6-oam-00

[Loa Andersson]

Zafar,

My concern is that any load balancing tool might hash on the field where
you have the O-bit, if it does OAM traffic and normal payload traffic
will take different paths through the network.

How do you guarantee  this this will not happen?

/Loa

On 2018-05-29 19:11, Zafar Ali (zali) wrote:

Hi Loa,

Thanks for your question.

O-bit "move" from SRH draft to this SRv6 OAM draft is part of a comment 
received an agreement made during the LC of the SRH draft. Please review 
the mail chain 
https://www.ietf.org/mail-archive/web/ipv6/current/msg30131.html. There 
was never a suggestion or agreement to "remove" O-bit or SRH.Flags field.


Load balancing and ECMP in an SRv6 network are explained in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-13#section-4.4. 
An implementation is expected to use the minimum of (source, dest) 
address and flow label in the outer IPv6 header to compute the hash. 
RFC6437 describes the use of flow labels to compute a hash for IPv6 
packets.


Thanks

Regards … Zafar

*From: *Loa Andersson 
*Date: *Tuesday, May 29, 2018 at 9:48 AM
*To: *Huzhibo , "Zafar Ali (zali)" , 
"draft-ali-spring-srv6-...@ietf.org" 
, "spring@ietf.org" 

*Cc: *Lizhenbin , Yangang 
*Subject: *Re: [spring] About draft-ali-spring-srv6-oam-00

Folks,

I thought we had an agreement to remove the O-bit. As ZhiBo Hu points

out other drafts drops it.

The obvious reason to not use an O-bit is that if it ever is part of

what an multipath functions hash on it will csue OAM traffic and

"normal" traffic to use different paths. This defeats the idea with

OAM traffic.

/Loa

On 2018-05-16 06:56, Huzhibo wrote:

Hi,

draft-ali-spring-srv6-oam-00 says The OAM packets are identified by

setting the O-bit in SRH，But I Notice the latest

I-D.6man-segment-routing-headerhas removed O-bit in the SRH extension

header. I want to confirm that draft-ali-spring-srv6-oam-00 will also

remove o-bit or keep the o-bit in the later version?

Ths

ZhiBo Hu

___

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

    https://www.ietf.org/mailman/listinfo/spring

--

Loa Anderssonemail: l...@pi.nu<mailto:l...@pi.nu>

Senior MPLS Expert

Bronze Dragon Consulting phone: +46 739 81 21 64



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



--


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

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

[spring] Closed: should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

[Loa Andersson]

Working Group,

This poll has been closed.

We have no objections to publishing draft-ietf-mpls-spring-entropy-label
as a RFC on the standards track. We also seem to have some support for
adding information that an entropy label is not necessarily the only
method handling ECMP.

I will forward this to Deborah (AD responsible for this document).

/Loa

On 2018-05-02 09:44, Loa Andersson wrote:

Working Group,

February 1st the MPLS working Group requested that draft-ietf-mpls-
spring-entropy-label should be published as an Informational RFC.

During the RTG Directorate and AD reviews the question whether the
document should instead be published as a RFC on the Standards Track
has been raised.

The decision to make the document Informational was taken "a long time
ago", based on discussions between the authors and involving the
document shepherd, on the wg mailing list. At that point it we were
convinced that the document should be progressed as an Informational
document.

It turns out that there has been such changes to the document that we
now would like to request input from the working group if we should make
the document a Standards Track RFC.

Daniele's RTG Directorate review can be found at at:
https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/ 



All the issues, with the exception whether it should be Informational
or Standards track, has been resolved as part AD review.

If the document is progressed as a Standard Tracks document then we
also need to answer the question whether this is an update RFC 6790.

This mail starts a one week poll (ending May 9) to see if we have
support to make the document a Standards Track document. If you support
placing it on the Standards Track also consider if it is an update to
RFC 6790.

Please send your comments to the MPLS wg mailing list ( m...@ietf.org ).

/Loa
for the mpls wf co-chairs

PS

I'm copying the spring working group on this mail.


--


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

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

Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

[Loa Andersson]

Eric, Stewart, wg,

Wouldn't just a few words in the draft saying something along the lines

"This document should not be interpreted in such a way that the ECMP
 behavior is limited to rely on EL only."

Go a long way to clarify Stewart's concerns?

/Loa

On 2018-05-02 16:52, Eric Gray wrote:

Stewart, et al,

     Loa just pointed out that I made a typo in the original 
mail below.  In the second paragraph, I meant to say:


     “Explicitly limiting ECMP behavior to …”

--

Eric

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Eric Gray
*Sent:* Wednesday, May 02, 2018 10:28 AM
*To:* Stewart Bryant <stewart.bry...@gmail.com>; Andrew G. Malis 
<agma...@gmail.com>; Loa Andersson <l...@pi.nu>
*Cc:* m...@ietf.org; spring@ietf.org; mpls-...@ietf.org; 
draft-ietf-mpls-spring-entropy-la...@ietf.org
*Subject:* Re: [mpls] [spring] should 
draft-ietf-mpls-spring-entropy-label be published as a RFC on the 
standards track?


Stewart,

     At least one view of the purpose of an Entropy label is 
that it _/adds/_ entropy to the process of path selection.


     Explicitly limiting EL behavior to rely exclusively on 
use of the entropy label would also explicitly _/limit/_ the total 
entropy to whatever the implementation that provided the entropy label 
was implemented to treat as _/sufficient/_ among all paths in the ECMP 
gestalt, possibly including branches that implementation might not know 
about.


     I doubt very much that many of the problems you refer 
to would have arisen if folks generally felt that the entropy label – by 
itself – provides sufficient entropy.


     It might make sense to impose this restriction – 
optionally – when a deployment occurs in which any particular 
pathological behavior might be expected to occur.


     In that case, it might be very important to ensure that 
the limited approaches available for maximizing efficient load 
distribution via explicit and exclusive use of the entropy label are 
acceptable to a reasonably diverse set of implementers, as support for 
at least one of those approaches would then become a mandatory part of 
every standard implementation.


     Even so, I don’t believe it is a good idea to restrict 
implementations from using other approaches in every case.


     The simplest example possible (where doing so is a big 
problem) is one where the entropy labels provided have N possible 
values  and there are M possible paths, where M>N. In any scenario where 
this occurs, M-N paths simply will not be used.


--

Eric

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Stewart Bryant
*Sent:* Wednesday, May 02, 2018 9:52 AM
*To:* Andrew G. Malis <agma...@gmail.com <mailto:agma...@gmail.com>>; 
Loa Andersson <l...@pi.nu <mailto:l...@pi.nu>>
*Cc:* m...@ietf.org <mailto:m...@ietf.org>; spring@ietf.org 
<mailto:spring@ietf.org>; mpls-...@ietf.org <mailto:mpls-...@ietf.org>; 
draft-ietf-mpls-spring-entropy-la...@ietf.org 
<mailto:draft-ietf-mpls-spring-entropy-la...@ietf.org>
*Subject:* Re: [mpls] [spring] should 
draft-ietf-mpls-spring-entropy-label be published as a RFC on the 
standards track?


Be careful.

There is text in the draft that talks about ECMP behaviour in different 
parts of the path, which implies an expectation that the EL is the sole 
source of entropy. If we make this ST then we will be implicitly 
standardizing that behaviour. Now as it happens, I thing we need to 
update the EL behaviour to make it the sole source of entropy, because 
that solves a number of problems, particularly in network 
instrumentation, but we need to do that explicitly and not as an 
artefact of this draft.


So the way I see it, either this draft is published as informational, or 
it is published as ST without any text that implies that the EL is the 
sole source of entropy, or we harden the EL behaviour (which I think we 
need to do) and this draft is published with a normative reference to an 
RFC that specifies the stricter EL behaviour.


- Stewart

On 02/05/2018 14:01, Andrew G. Malis wrote:

Loa,

There’s plenty of RFC 2119 language in the draft, so I support
making this standards track.

Cheers,

Andy

On Wed, May 2, 2018 at 3:44 AM, Loa Andersson <l...@pi.nu
<mailto:l...@pi.nu>> wrote:

Working Group,

February 1st the MPLS working Group requested that draft-ietf-mpls-
spring-entropy-label should be published as an Informational RFC.

During the RTG Directorate and AD reviews the question whether the
document should instead be published as a RFC on the Standards Track
has been raised.

The decision to make the document Informational was taken "a
long time
ago", based on discussions between the authors and involving the
do

Re: [spring] [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

[Loa Andersson]

mpls mailing list
m...@ietf.org<mailto:m...@ietf.org>

https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>

__ __

___________
mpls mailing list
m...@ietf.org<mailto:m...@ietf.org>

https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>

__ __






___
mpls mailing list
m...@ietf.org <mailto:m...@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls
<https://www.ietf.org/mailman/listinfo/mpls>




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



--


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

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

[spring] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

[Loa Andersson]

Working Group,

February 1st the MPLS working Group requested that draft-ietf-mpls-
spring-entropy-label should be published as an Informational RFC.

During the RTG Directorate and AD reviews the question whether the
document should instead be published as a RFC on the Standards Track
has been raised.

The decision to make the document Informational was taken "a long time
ago", based on discussions between the authors and involving the
document shepherd, on the wg mailing list. At that point it we were
convinced that the document should be progressed as an Informational
document.

It turns out that there has been such changes to the document that we
now would like to request input from the working group if we should make
the document a Standards Track RFC.

Daniele's RTG Directorate review can be found at at:
https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/

All the issues, with the exception whether it should be Informational
or Standards track, has been resolved as part AD review.

If the document is progressed as a Standard Tracks document then we
also need to answer the question whether this is an update RFC 6790.

This mail starts a one week poll (ending May 9) to see if we have
support to make the document a Standards Track document. If you support
placing it on the Standards Track also consider if it is an update to
RFC 6790.

Please send your comments to the MPLS wg mailing list ( m...@ietf.org ).

/Loa
for the mpls wf co-chairs

PS

I'm copying the spring working group on this mail.
--


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

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

Re: [spring] SPRING - rechartering discussion

[Loa Andersson]

Martin,

I think we fully agree!

/Loa

On 2018-03-20 13:37, Martin Horneffer wrote:

Hi Loa,

this looks like some kind of misunderstanding, probably due my 
sloppiness with respect to formal and organizational requirements. I'm 
really sorry for that. My everyday job keeps me busy enough with formal 
requirements, associated tasks, and organizational thinking. Thus I 
really appreciate that other people take care of all that at the IETF.


In other words, I don't in any way oppose a rechartering discussion. All 
I wanted is to say: please let this WG keep going for a while, I really 
think it's needed. And I think it's best done with exactly the group we 
have right now.


If this needs refining or adding milestones, that's fine for me. If it 
requires some rechartering, then ok, too. Just keep the group and allow 
all the mentioned topics to be discussed here.


Best regards, Martin


Am 19.03.18 um 10:12 schrieb Loa Andersson:


Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into 
production networks, I get the strong feeling that SPRING is not done 
with the conclusion of the core documents. As the technology gets 
closer to production use, unforeseen topics and issues appear that 
need to be discussed and - in many cases - standardized. I do see the 
need for documents of the "operators' requirements" style.


I take that you don't entirely agree with the "core documents almost
done" in the mail that Marin and Bruno sent starting up the
re-chartering discussion. I think I see your point and the things you
point at certainly needs to be addressed.

Sorry if I misunderstand what you are saying. I don't see the "not
completed" as a reason not take the discussion and actually recharter.
Working do this quite often, since more understanding of the area is
gained through the work done, but at the same time we also see a shift
in focus that we need to capture.

/Loa





--


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

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

[spring] working group for draft-xu-mpls-sr-over-ip

[Loa Andersson]

SPRING and MPLS working groups,

Working Groups,

We have had a discussion on the correct working group for the merged
draft-xu-mpls-sr-over-ip.

After consulting with the RTG ADs, RTG ADs decided that the working 
group will be MPLS, but that the draft will need to be discussed in

SPRING extensively.

Bruno, Nic, Rob, Loa and George
MPLS and SPRING wg co-chairs

--


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

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

Re: [spring] SPRING - rechartering discussion

[Loa Andersson]

Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into 
production networks, I get the strong feeling that SPRING is not done 
with the conclusion of the core documents. As the technology gets closer 
to production use, unforeseen topics and issues appear that need to be 
discussed and - in many cases - standardized. I do see the need for 
documents of the "operators' requirements" style.


I take that you don't entirely agree with the "core documents almost
done" in the mail that Marin and Bruno sent starting up the
re-chartering discussion. I think I see your point and the things you
point at certainly needs to be addressed.

Sorry if I misunderstand what you are saying. I don't see the "not
completed" as a reason not take the discussion and actually recharter.
Working do this quite often, since more understanding of the area is
gained through the work done, but at the same time we also see a shift
in focus that we need to capture.

/Loa

--


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

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

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

[Loa Andersson]

Zafar,

On 2018-03-09 08:02, Zafar Ali (zali) wrote:

*Summary*:

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




Interesting, can you point me to the RFC and text that we broke?

/Loa

--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

[spring] Closed -- working group last call on draft-ietf-mpls-spring-entropy-label

[Loa Andersson]

Working Group,

This working group last call is closed, we have support to request
publication.

Authors, should verify that they are ready to go ahead with the current
version, or indicate that they want to do updates.

The document shepherd will start preparing the shepherd write-up.

/Loa

On 2017-12-08 21:17, Loa Andersson wrote:

Working Group,

This is to initiate a two week working group last call on draft-
ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (m...@ietf.org).

Since this is a second wglc on this document, the current document
address all comments all comments from the previous wglc, but it is
more than 18 months since the previous wqglc, we have decided to do
a full two week call.

There are no IPRs disclosed against draft-ietf-mpls-spring-entropy-
label.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

This working group last call ends December 22, 2017.

This wglc is copied to the SPRING wg mailing list, please address all
comments to m...@ietf.org.


/Loa
MPLS wg co-chair


--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

[spring] working group last call on draft-ietf-mpls-spring-entropy-label

[Loa Andersson]

Working Group,

This is to initiate a two week working group last call on draft-
ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (m...@ietf.org).

Since this is a second wglc on this document, the current document
address all comments all comments from the previous wglc, but it is
more than 18 months since the previous wqglc, we have decided to do
a full two week call.

There are no IPRs disclosed against draft-ietf-mpls-spring-entropy-
label.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

This working group last call ends December 22, 2017.

This wglc is copied to the SPRING wg mailing list, please address all
comments to m...@ietf.org.


/Loa
MPLS wg co-chair
--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

Re: [spring] Working group last call on draft-ietf-mpls-spring-lsp-ping

[Loa Andersson]

Working Groups,

This working group last call has been closed.

There have been comments, can the authors/editors please update as
necessary and post a new version.

/Loa

On 2017-07-11 11:35, Loa Andersson wrote:

Working Groups,

This is to initiate a two week MPLS working group last call in on
draft-ietf-mpls-spring-lsp-ping-03.

Please send your comments to the mpls wg mailing list (m...@ietf.org).

There are no IPR disclosures against this document.

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates
to this document.

As usual when a wglc is across an IETF week we do not count that week,
this working group last call therefore ends August 1, 2017.


/Loa
MPLS wg co-chairs

PS

I was a bit trigger happy and started this wglc with an ambiguous
subjet. Please use this mail when you are responding to the wglc.


--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

[spring] IPR poll on draft-ietf-mpls-spring-lsp-ping

[Loa Andersson]

Working Group, authors,

We have started to prepare the the draft-ietf-mpls-spring-lsp-ping for
wglc, prior to the wglc we need to do an IPR poll.

This mail starts this IPR poll.

Are you aware of any IPR that applies to
draft-ietf-mpls-spring-lsp-ping?

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

No IPR disclosures have been submitted directly on draft-ietf-mpls-
spring-lsp-ping or the individual document it replaced.

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

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

Since this document might be of interest for the SPRING wg, it has been
copied to the SPRING wg mailing list.

/Loa
mpls wg co-chair
--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

[spring] SR / LDP Interop

[Loa Andersson]

Authors,

I have a question, that I hope have a simple and documented answer, only
that I can't find it. LDP has messages like Label Release, Label Abort
Request and Label Withdraw. How does SR handle those?

/Loa
--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

Re: [spring] draft-kumarkini-mpls-spring-lsp-ping

[Loa Andersson]

Bruno,

Tnx for helping make this work know in spring.

We are not entirely ready to call for working group adoption yet, need
an updated version of the draft.

I will tell the spring wg when we do so, but it is not a bad time to
read and comment now.

/Loa

On 2015-09-28 16:40, bruno.decra...@orange.com wrote:

Hi,

FYI, This draft is of interest to the SPRING WG and you may want to have a look 
at it: https://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping
Title: Label Switched Path (LSP) Ping/Trace for Segment Routing 
Networks Using MPLS Dataplane
Abstract: This document illustrates the problem and describe a 
mechanism to perform LSP Ping and Traceroute on Segment Routing network over 
MPLS data  plane.

It's being discussed in the MPLS WG, with recent MPLS-RT reviews: 
https://mailarchive.ietf.org/arch/search/?q=subject%3A%28MPLS-RT+draft-kumarkini-mpls-spring-lsp-ping%29=1=y

It's expected to be polled for adoption in the MPLS WG sometime soon.

--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

[spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

[Loa Andersson]

Hello,

I have been selected as the Routing Directorate QA reviewer for
draft-filsfils-spring-segment-routing-mpls-03.txt.

The Routing Directorate QA reviews are intended to be a support to
improve the quality of RTG Area documents as the pass through the IETF
process.

This is the QA review at the time of wg document adoption poll.

Document: draft-filsfils-spring-segment-routing-mpls-03.txt
Reviewer: Loa Andersson
Review Date: 2014-09-28
Working Group Adoption Poll end date: Oct 8, 2014
Intended Status: Standards Track

Please find the review at:

http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014

/Loa

--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

[Loa Andersson]

Sasha,

I did NOT mean to imply that this discussion in the MPLS wg should
wait until the SPRING wg last call, on the contrary if the answer to
my question is that this a domain wide label, then it has to be brought
to the MPLS wg BEFORE this is adopted as a SPRING wg document.

/Loa

On 2014-09-29 14:28, Alexander Vainshtein wrote:

I concur with you that this requires discussion in the MPLS WG, and I am not 
sure such a discussion should be postponed until the SPRING WG LC.


--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

[Loa Andersson]

Stefano,

I'm fine with that, but I guess that the SPRING wg chairs and/or the
rtg AD's need to make the consensus call on that.

/Loa

On 2014-09-29 16:00, Stefano Previdi (sprevidi) wrote:

On Sep 29, 2014, at 3:52 PM, Loa Andersson wrote:

Sasha,

I did NOT mean to imply that this discussion in the MPLS wg should
wait until the SPRING wg last call, on the contrary if the answer to
my question is that this a domain wide label, then it has to be brought
to the MPLS wg BEFORE this is adopted as a SPRING wg document.



I agree with you and the answer is no we don't want to bring a discussion 
about domain-wide labels because this is not a requirement of segment routing.

s.




/Loa

On 2014-09-29 14:28, Alexander Vainshtein wrote:

I concur with you that this requires discussion in the MPLS WG, and I am not 
sure such a discussion should be postponed until the SPRING WG LC.


--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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




--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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