[spring] Alia Atlas' No Objection on draft-ietf-spring-problem-statement-06: (with COMMENT)

2016-01-20 Thread Alia Atlas
Alia Atlas has entered the following ballot position for
draft-ietf-spring-problem-statement-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/



--
COMMENT:
--

A terminology section and describing at all the bullets of desired
functionality would
improve the readability.  This draft doesn't feel as if it will be a
useful RFC in 2 years.


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


[spring] Alissa Cooper's No Objection on draft-ietf-spring-problem-statement-06: (with COMMENT)

2016-01-20 Thread Alissa Cooper
Alissa Cooper has entered the following ballot position for
draft-ietf-spring-problem-statement-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/



--
COMMENT:
--

(1)
I'm surprised that almost all of the requirements in this document are
SHOULDs, since they mostly apply to an architecture and not individual
solutions. In general I think it would help to explain the exception
cases or the rationale for uncertainty about what the architecture will
or won't support.

(2)
The security considerations section here appears to borrow text from the
SPRING WG charter, but then is actually less specific than the charter
about the anticipated mitigations that the SPRING architecture will
provide against known threats. Given the structure of this document I
would have expected detailed security requirements that any SPRING
solution will be required to meet.


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


Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

2016-01-20 Thread Stefano Previdi (sprevidi)
Hi Stephane,

I agree with you.

I also noticed that in draft-ietf-spring-segment-routing-mpls we should have 
(probably) a better description on how to use SRGB and indexes.

I propose to update draft-ietf-spring-segment-routing-mpls so that the 
conflict-resolution draft can point to it when referring to  SRGB/index 
procedures.


s.


> On Jan 19, 2016, at 9:46 AM, stephane.litkow...@orange.com wrote:
> 
> Hi Les,
>  
> IMO, “treat the sending node as NOT SR-MPLS capable for globally scoped SIDs” 
> may lead to confusion and let think that only Adj-SID can be used.
> “NOT SR-MPLS capable” is really strong, and may prevent the PHP case  Bruno 
> was describing.
> May be we can add a sentence to precise what the statement means like : “This 
> means that the sending node is not able to process MPLS labels mapped to 
> globally scope SIDs.”.
>  
>  
> Stephane
>  
>  
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Saturday, January 16, 2016 01:13
> To: Uma Chunduri; DECRAENE Bruno IMT/OLN
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> It is true that the neighbor of the dysfunctional node cannot install 
> outgoing labels for paths via the dysfunctional node. That is precisely the 
> meaning of “treat the sending node as NOT SR-MPLS capable for globally scoped 
> SIDs”.
>  
> This does not mean that “global SID advertisements should be ignored”. And I 
> do not see that it could in any way be interpreted to imply that.
>  
> Please hit the “reset button” and try looking at this with a fresh 
> perspective. J
>  
>Les
>  
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 3:56 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> In-line [Uma]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Friday, January 15, 2016 12:22 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> I have no idea how you translate:
>  
> Receivers of an invalid SRGB MUST ignore the SRGB and treat the sending node 
> as NOT SR-MPLS capable for globally scoped SIDs.
>  
> into
>  
> Should not consider any global SIDs, because the advertised global SIDs are 
> not trustworthy any more
>  
> SRGB defines the node-local label space which has been reserved for use by SR 
> on that node.
> [Uma]:  …and also the upstream neighboring node to compute and install the 
> outgoing label J.
>  
> Global SIDs define the index which is to be used into the node specific SRGBs 
> to map the index into the correct node-specific label.
> [Uma]: ..of both advertising node’s own SRGB locally and the SRGB of computed 
> shortest path neighbor.
>  
> While I will do my best to make the language in the draft clear and 
> unambiguous,
>  
> [Uma]: thx!
>  
> I am frankly at a loss to understand how you concluded that the SRGB related 
> statement says anything whatsoever about SID advertisements.
> [Uma]: because of this
> “sending node as NOT SR-MPLS capable for globally scoped SIDs”
> hence the conclusion of not using the global SIDs!!
>  
>  
>Les
>  
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Friday, January 15, 2016 10:13 AM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Les,
>  
> Thanks. My quick response below [Uma2]:
>  
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Thursday, January 14, 2016 5:28 PM
> To: Uma Chunduri; bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Uma –
>  
> Thanx for the response.
> Inline.
>  
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com] 
> Sent: Thursday, January 14, 2016 3:34 PM
> To: Les Ginsberg (ginsberg); bruno.decra...@orange.com
> Cc: spring@ietf.org; Henderickx, Wim (Wim)
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB 
> INCONSISTENCY
>  
> Dear Les, Bruno, 
>  
> Thanks for a great discussion on this sticky issue.
>  
> Couple of things:
>  
> 1.   Les, I support advertising explicit SR capability of the node; 
> meaning this doesn’t have  to be tied to one or more SRGB range 
> advertisements.
> Though for example, OSPF draft doesn’t say anything about ‘no srgb ranges’ in 
> SID/Label Range TLV, my vote is to be explicit about it.
> I also agree to change IS-IS document to change and to align to the