Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

2019-04-17 Thread Ahmed Bashandy 
Version 21 of the draft has just been uploaded, I removed the sentence 
“IGPs with SR extensions...are examples of MCCs.”.


as you suggested since I overlooked removing it in version 20 which was 
uploaded few hours ago


Thanks

Ahmed
On 4/10/19 3:05 PM, Alvaro Retana wrote:
On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia - 
FR/Paris-Saclay) (martin.vigour...@nokia.com 
) wrote:


Martin:

Hi!


It looks to me that you don’t disagree with what is written in the 
draft but rather with the fact that the draft may suggest that IGPs 
should do things which are in fact not specified in the IGPs drafts. 
I think this point covers 1.1 to 1.4


Assuming that I’m correct, I believe that in order to clear the 
misunderstanding authors could simply remove the sentence: “IGPs with 
SR extensions...are examples of MCCs.”.


…and probably clean up some other text, for example, §2.10.1 
references I-D.ietf-isis-segment-routing-extensions specifically.


Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 
8402. It is not saying “An IGP Node-SID SHOULD NOT be associated with 
a prefix …”


The way I see it is that this is a belt and suspenders approach. The 
base req says MUST NOT and this req says “check if this req is 
respected”.


I read this document as saying “check, but you may have reasons not 
to”…  IMHO, there’s no reason to specify the behavior here again, if 
it’s already specified in rfc8402.



Of course this is only my view. I expect authors to have their own.


I’m sure they will. ;-)

Thanks!

Alvaro.



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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

2019-04-10 Thread Alvaro Retana 
On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia -
FR/Paris-Saclay) (martin.vigour...@nokia.com) wrote:

Martin:

Hi!

It looks to me that you don’t disagree with what is written in the draft
but rather with the fact that the draft may suggest that IGPs should do
things which are in fact not specified in the IGPs drafts. I think this
point covers 1.1 to 1.4

Assuming that I’m correct, I believe that in order to clear the
misunderstanding authors could simply remove the sentence: “IGPs with SR
extensions...are examples of MCCs.”.

…and probably clean up some other text, for example, §2.10.1
references I-D.ietf-isis-segment-routing-extensions specifically.

Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It
is not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”

The way I see it is that this is a belt and suspenders approach. The base
req says MUST NOT and this req says “check if this req is respected”.

I read this document as saying “check, but you may have reasons not to”…
 IMHO, there’s no reason to specify the behavior here again, if it’s
already specified in rfc8402.

Of course this is only my view. I expect authors to have their own.

I’m sure they will. ;-)

Thanks!

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

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-exten

2019-04-10 Thread Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
Alvaro,

Thanks for your review. I’m not sure whether I should reply here or on the 
iesg’s list.
It looks to me that you don’t disagree with what is written in the draft but 
rather with the fact that the draft may suggest that IGPs should do things 
which are in fact not specified in the IGPs drafts. I think this point covers 
1.1 to 1.4
Assuming that I’m correct, I believe that in order to clear the 
misunderstanding authors could simply remove the sentence: “IGPs with SR 
extensions...are examples of MCCs.”.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It is 
not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”
The way I see it is that this is a belt and suspenders approach. The base req 
says MUST NOT and this req says “check if this req is respected”.

Of course this is only my view. I expect authors to have their own.

-m


From: Alvaro Retana 
Sent: Wednesday, April 10, 2019 22:31
To: draft-ietf-spring-segment-routing-mpls@ietf.org; 
draft-ietf-ospf-segment-routing-extensions@ietf.org; 
draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org; 
draft-ietf-isis-segment-routing-extensions@ietf.org
Cc: SPRING WG ; l...@ietf.org
Subject: Fwd: Alvaro Retana's Discuss on 
draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) 
(draft-ietf-ospf-segment-routing-extensions / 
draft-ietf-ospf-ospfv3-segment-routing-extensions / 
draft-ietf-isis-segment-routing-extensions)

Hi!

I just entered a DISCUSS position related to 
draft-ietf-spring-segment-routing-mpls (see below).  I believe that the issue 
needs to be solved in conjunction with the IGP extension drafts, so I’m copying 
the authors/shepherds/chairs here.

Thanks!

Alvaro.


On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker 
(nore...@ietf.org) wrote:
--
DISCUSS:
--

(1) This first point is a cross-document DISCUSS. In short, the assumptions in
this document about what an MCC is responsible for are not in line with the
corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment must
be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
Chairs and ADs. Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane
Client (MCC)" any control plane entity installing forwarding entries in the
MPLS data plane. IGPs with SR extensions...are examples of MCCs."

The focus of the IGP drafts is on the transport of the SR information, and not
on other functions (see below). Which component is responsible for what is the
point that needs clarification -- either in this document, the IGP drafts, or
both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
applied by the MCC when calculating the MPLS label value corresponding the SID
index value "I"." There's nothing in the IGP extension documents that point at
this set of rules, and only a passing reference in the OSPF documents about
outgoing labels.

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
than what the IGP documents do. For example: "Within an MCC, apply
tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
downloading the correct label value to FIB"...in this case not just calculating
the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
this document. An example of a method to determine the SID "Si" for PUSH
operation is the case where IS-IS
[I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
the OSPF ones, for that matter) don't talk about how to determine the operation
-- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

An implementation SHOULD check that an IGP node-SID is not associated
with a prefix that is owned by more than one router within the same
routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
that is owned by more than one router within the same routing domain." The
text above is not in line with that (MUST NOT vs SHOULD). Also, how can
"SHOULD check" be Normatively enforced?

Both sentences above seem to be trying to specify a behavior for the IGPs.

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2]
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3]