Re: [spring] Request WG adoption for draft-xuclad-spring-sr-service-chaining-01

[徐小虎(义先)]

Hi SPRING WG co-chairs,
I wonder what the current status of this WG adoption request.
Best 
regards,Xiaohu--From:徐小虎(义先)
 Send Time:2018年4月4日(星期三) 09:45To:SPRING WG List 
Cc:s...@ietf.org Subject:Request WG adoption 
for draft-xuclad-spring-sr-service-chaining-01

Hi SPRING WG co-chairs,
We authors believe this draft 
(https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01) has 
been stable enough and therefore we would like to request a WG adoption call 
for it.
We believe this work belongs to SPRING WG since the concept of service segment 
has been mentioned in the Segment Routing architecture from day one and the 
approaches as described in this draft are exactly to leverage the stateless 
source routing capability of segment routing to achieve a stateless SFC. To 
some extent, SFC can be looked as a special case of source routing as it 
requires the selected traffic to traverse an ordered list of service nodes.

We believe the SFC WG review is still needed after the adoption since we still 
hope to reuse the NSH for some special purposes (e.g., use it as a metadata 
container). 
BTW, implementations based on this draft have existed, as noted in section 8 of 
the draft.
Best regards,Xiaohu (on behalf of coauthors)




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

[Stewart Bryant]

Well, yes and no.

Presumably routers know what they are load balancing on and can report 
that to the control & management plane, a path can be chosen that 
explicitly takes a path based on the desired behaviour.


Also presumably if there is a need, the ECMP behaviour could be modified 
to only use the EL.


My big concern is that there are a number of instrumentation (and maybe 
path construction) cases where we really would like to see EL only ECMP.


- Stewart


On 02/05/2018 16:03, John E Drake wrote:


Stewart,

Realistically, I think your proposal is an example of closing the barn 
door after the horse has bolted.


Yours Irrespectively,

John

*From:*spring  *On Behalf Of *Eric Gray
*Sent:* Wednesday, May 2, 2018 10:28 AM
*To:* Stewart Bryant ; Andrew G. Malis 
; Loa Andersson 
*Cc:* m...@ietf.org; spring@ietf.org; mpls-...@ietf.org; 
draft-ietf-mpls-spring-entropy-la...@ietf.org
*Subject:* Re: [spring] [mpls] 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 >; 
Loa Andersson >
*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?


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

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 ; Andrew G. Malis 
; Loa Andersson 
*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 >; 
Loa Andersson >
*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?


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

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

[Eric Gray]

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 ; Andrew G. Malis 
; Loa Andersson 
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 >; Loa 
Andersson >
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?


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

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

[Eric Gray]

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 ; Loa Andersson 
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?


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

___
mpls mailing list

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

[Stewart Bryant]

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 > 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 Andersson                        email: l...@pi.nu

Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

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





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


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

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

[Alexander Vainshtein]

Loa and all,
+1.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Andrew G. Malis
Sent: Wednesday, May 2, 2018 4:01 PM
To: Loa Andersson 
Cc: m...@ietf.org; spring@ietf.org; mpls-...@ietf.org; 
draft-ietf-mpls-spring-entropy-la...@ietf.org
Subject: Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be 
published as a RFC on the standards track?

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

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


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___
___
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?

[Andrew G. Malis]

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

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

[Loa Andersson]

Andy,

The chairs of the SPRING and MPLS wg has discussed the proposal to
adopt draft-xuclad-spring-sr-service-chaining in the MPLS wg.
Our agreement is that draft-xuclad-spring-sr-service-chaining
belongs in the SPRING wg.

/Loa
for the SPRING and MPLS wg co-chairs

On 2018-04-15 16:55, Andrew G. Malis wrote:

Zafar, et al,

Perhaps the fairest to all concerned is for the MPLS WG to adopt both 
drafts, and then it will be up to the WG (rather than the authors) to 
best determine the technical details going forward, and how best to 
document them. That way the work becomes the consensus product of the WG.


Cheers,
Andy


On Sun, Apr 15, 2018 at 12:44 AM, Zafar Ali (zali) > wrote:


Dear Stewart, WG Chairs and the WG, 

__ __

I do not agree with Stewart’s points and will response in a separate
email. But all that is just noise and that cannot resolve the issue
at hand. 

__ __

A countless time, Xiaohu has raised the issue that the intellectual
property for the contents in section 6 of draft-farrel-mpls-sfc
belongs to draft-xu-mpls-service-chaining. Please see one of
Xiaohu's recent emails with the subject *"[spring] For the fairness
and justice of the IETF culture"* dated Thursday, April 5, 2018 at
12:34 AM, copied in the following. 

__ __

This issue was also raised by many during the WG adoption poll of
the document. The chairs adopted the work with the promise of fixing
the issue. Specifically, in the email to announce the adoption of
the ID to the WG, the chair(s) mentioned the following:

__ __

"That decision is taken, the issues that has been pointed out are

noted. These issues need to be resolved on the mailing list and

rough consensus need to be reached for text changes in the document.

Actually the members of the working group have much more influence
on

a working group document, than on an individual draft.

It would be far better if we now focused on proposing text changes,

rather than discussing processes."

__ __

This is a serious issue; we need to remove section 6 from draft-
farrel-mpls-sfc to move forward. These contents will proceed in
draft-xu*, where the contents started initially. Everyone will have
a fair chance to contribute to the contents as part of
collaborations on draft-xu*. __ __

__ __

Thanks

__ __

Regards … Zafar 

__ __

*From: *spring > on behalf of "徐小虎(义先)"
>
*Date: *Thursday, April 5, 2018 at 12:34 AM
*To: *"m...@ietf.org " >, SPRING WG List >
*Cc: *"i...@ietf.org " >
*Subject: *[spring] For the fairness and justice of the IETF
culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

__ __

Hi all,

__ __

As I had pointed out before, this draft describes two MPLS-based SFC

approaches: one is how to encode the NSH info, more specifically,
the SPI

and SI info by two MPLS labels, which is still a stateful SFC
mechanism

just like NSH; another is how to leverage the MPLS-SR to realize a

stateless SFC (see section 6).

__ __

It has been pointed out by many people that section 6 of the draft
copies

the

idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining
)

without any technology contribution except replacing “MPLS Segment

Routing” by “Label Stack”. Funnily, one author of
draft-ietf-mpls-sfc

had inadvertently admitted

"using a different name for the same thing is not so clever" (see

https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc
)
in

another thread. 

__ __

IMHO, the indulgence towards such behavior of copying

ideas of existing drafts with word tricks would seriously trample

underfoot the fairness and justice of the IETF culture. At least, it
would

badly damage the interest and enthusiasm of IETF participants,
especially

newcomers and non-native speakers of English.

__ __

Best regards,

Xiaohu

__ __

__ __

__ __

__ __

*From: *mpls >
on behalf of Stewart Bryant >
*Date: *Friday, April 13, 2018 at 3:10 AM
*To: *"徐小虎(义先)" 

[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