[spring] draft-ietf-spring-segment-routing-mpls-12

[bruno.decraene]

Ahmed, authors,
Thanks for the work updating this document, answering Alvaro’s comment and 
presenting at London.


WG,
This draft has been returned to the WG by the AD.
Please have a look at the document and comment, especially as the changes are 
non-trivial.

In particular, as indicated by Ahmed, this draft now covers the handling of 
incoming and outcoming label collision and as a result my understanding is that 
the WG draft draft-ietf-spring-conflict-resolution will not be pursued.
If you have reviewed or commented on draft-ietf-spring-conflict-resolution 
during its working group last call, you are likely interested in reviewing 
draft-ietf-spring-segment-routing-mpls and checking whether your comments are 
addressed.

Finally, the document shepherd was Martin who is now serving as routing AD. Rob 
and I both co-authors this draft so it’s not appropriate for us to be shepherd.
Shraddha has agreed to shepherd this document; Thank you Shraddha.

--Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ahmed Bashandy 
(bashandy)
Sent: Thursday, March 08, 2018 6:18 PM
To: spring@ietf.org
Subject: [spring] Fwd: New Version Notification for 
draft-ietf-spring-segment-routing-mpls-12.txt


Hi,

Here is a new version of the draft. This version has non-trivial changes from 
the previous one. Here is a summary of the changes
- Specifications of the rules governing SRGB and SRLB
- Specification of how to translate a SID index into a label
- Specification of what a router do when receiving an SRGB advertisement that 
does not conform to the rules
- Handling incoming label collision
- Handling outgoing label collision
- Rules governing redistribution of routes that have SR-MPLS SIDs

Thanks

Ahmed

 Original Message 
Subject:

New Version Notification for draft-ietf-spring-segment-routing-mpls-12.txt

Date:

Fri, 23 Feb 2018 05:06:46 -0800

From:



To:

Ahmed Bashandy , Bruno Decraene 
, Clarence 
Filsfils , "Stefano Previdi" 
, Rob Shakir 
, "Stephane Litkowski" 




A new version of I-D, draft-ietf-spring-segment-routing-mpls-12.txt

has been successfully submitted by Ahmed Bashandy and posted to the

IETF repository.



Name: draft-ietf-spring-segment-routing-mpls

Revision: 12

Title:Segment Routing with MPLS data plane

Document date: 2018-02-23

Group:spring

Pages:24

URL:
https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-mpls-12.txt

Status: 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

Htmlized:   
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-12

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-12

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-12



Abstract:

   Segment Routing (SR) leverages the source routing paradigm.  A node

   steers a packet through a controlled set of instructions, called

   segments, by prepending the packet with an SR header.  In the MPLS

   dataplane, the SR header is instantiated through a label stack. This

   document specifies the forwarding behavior to allow instantiating SR

   over the MPLS dataplane.











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





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

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

[Adrian Farrel]

I, too, hope we can move to a technical discussion of the differences between 
the proposals and not spend time thrashing around in IETF politics. I'm sure 
the ADs will help us understand what is written in the various WG charters, so 
our best next step would be to read (you know, like all the words :-) what is 
in the drafts.
 
However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight.
 
He said...
 
> From IETF process viewpoint, this call for adaption is like putting the "cart 
> ahead of the horse."
> MPLS WG comes last in the process after there is an agreement from Spring and 
> SFC groups
> on the need for MPLS data plane changes proposed by the draft. I raised this 
> point at the mic
> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at 
> the last stage
> in the process; expert to review this work does not sit in the MPLS WG.
 
According to the minutes, Zafar said...
 
| Zafar Ali: before defining the solution, is this the right approach in SFC? 
Starting
| in MPLS WG is wrong thing to do.
 
And I responded...
 
| Adrian: This was already presented in SFC WG today.
 
In the SFC WG I said...
 
| - The draft discusses how MPLS can be used for SFC. It is being discussed in 
the
|MPLS working group.
| - We are looking at environments in which deployed MPLS routers can be used
|for creating an SFC, rather than using NSH.
 
If you want my opinion:
- The SFC WG is chartered to work on NSH only
- The MPLS WG is chartered to work on MPLS
- This draft asks for MPLS code points so can only be in MPLS
- This draft must be reviewed in SFC and SPRING as it progresses and
   certainly at WG last call
 
Adrian
 
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; draft-farrel-mpls-sfc; mpls-chairs; 
mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
Importance: High
 
Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc, 
 
I would like to draw your attention to the serious issue raised by Xiaohu and 
Francois. 
 
Summary:
 
Please note that this working group adaption against the IETF process and its 
spirit. Please recall the adaption call. 
 
Details: 
 
Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we 
discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc 
and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS 
WG. There was the specific conversation on which WG the work belongs, and the 
assumed follow-up was for the chairs and ADs to have the discussion on home for 
these drafts. 
 
>From IETF process viewpoint, this call for adaption is like putting the "cart 
>ahead of the horse." MPLS WG comes last in the process after there is an 
>agreement from Spring and SFC groups on the need for MPLS data plane changes 
>proposed by the draft. I raised this point at the mic at SFC WG meeting at 
>IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the 
>process; expert to review this work does not sit in the MPLS WG.
 
The drafts also did not stay dormant after IETF100. There were email 
conversations among the authors of the concerned drafts 
(https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA). 
 
Authors of draft-xu- and draft-clad- followed the proper IETF process, 
discussed and merged the contents. They published 
draft-xuclad-spring-sr-service-chaining-01 and asked WG for a "presentation 
slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to 
force this "WG adaption call"! 
 
One also has to question the timing of this adaption call when the WGs are 
meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to make 
use of the face-to-face to do the right thing, especially when we are meeting 
in two weeks?  
 
In the light of the above, my request to the authors of draft-farrel and MPLS 
WG chairs to please do the right thing and recall this WG adaptation call. 
 
Thanks
 
Regards ... Zafar
 
 
From: mpls  on behalf of "Francois Clad (fclad)" 

Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)" 
Cc: draft-farrel-mpls-sfc , "m...@ietf.org" 
, SPRING WG List , mpls-chairs 
, mpls 
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
 
Hi Xiaohu, all,

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

At IETF100, three 

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