Re: [spring] [mpls] What's the consensus among co-chairs and ADs regarding the better place for the SR-MPLS-over-IP work?

[Ahmed Bashandy (bashandy)]

I agree.

I remember I mentioned something similar at the mic during the SPRING WG 
meeting in the IETF in Singapore


The draft proposes a mechanism that allows forwarding SR-MPLS packets 
through a sub-domain that only understand pure IP. The draft suggests 
using MPLS in UDP tunneling (which is already an RFC) but does not 
propose any extensions to that mechanism or any other MPLS in IP mechanism


This means that the draft does not extend the MPLS control or forwarding 
plane. Instead it extends the source routing paradigm.


So IMO SPRING is the better place for this draft

Ahmed

On 3/15/2018 6:41 AM, Zafar Ali (zali) wrote:


Hi Xiaohu, Chairs and the ADs,

As this draft does NOT make any changes to the MPLS data plane and is 
related to the source routing, IMO, SPRING is the right home for the 
draft.


Ifyou look at meeting minutes of Spring WG at last IETF 
(https://datatracker.ietf.org/meeting/100/materials/minutes-100-spring) you 
will find the attending AD (Alvaro Retana) came to mic and said, 
regardless of the outcome of the merger “I (still) think this should 
be in SPRING”. Sounds like a done deal to me :--)


Thanks

Regards … Zafar

*From: *spring  on behalf of "徐小虎(义先)" 


*Reply-To: *"徐小虎(义先)" 
*Date: *Thursday, March 15, 2018 at 2:22 AM
*To: *"m...@ietf.org" , SPRING WG List 
*Subject: *[spring] What's the consensus among co-chairs and ADs 
regarding the better place for the SR-MPLS-over-IP work?


Dear co-chairs and ADs,

Alvaro as an AD said at last IETF meeting that let's wait and decide 
(on the better place for the SR-MPLS-over-IP work) 
(see https://datatracker.ietf.org/meeting/100/materials/minutes-100-spring), 
I wonder whether a rough consensus has been reached among co-chairs 
and ADs.


Best regards,

Xiaohu



___
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] Fwd: New Version Notification for draft-ietf-spring-segment-routing-mpls-12.txt

[Ahmed Bashandy (bashandy)]

As you mentioned draft-ietf-spring-conflict-resolution has already expired.
draft-ietf-spring-segment-routing-mpls covers local label collision only 
that is totally independent of any routing protocols and is a lot simpler.


Ahmed


On 3/8/2018 9:28 AM, Rob Shakir wrote:

Hi Ahmed,

Thanks for the update to the WG.

Would it be possible for you and the authors of 
draft-ietf-spring-conflict-resolution to clarify what the intention is 
for that draft when compared to this one? The additions in sections 
2.5. and 2.6 of this draft seem to cover the same material as covered 
in that draft - and the conflict resolution draft has expired.


Thank you!
r.


On Thu, Mar 8, 2018 at 6:17 PM Ahmed Bashandy (bashandy) 
<basha...@cisco.com <mailto:basha...@cisco.com>> wrote:



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:   <internet-dra...@ietf.org> <mailto:internet-dra...@ietf.org>
To: Ahmed Bashandy <basha...@cisco.com>
<mailto:basha...@cisco.com>, Bruno Decraene
<bruno.decra...@orange.com> <mailto:bruno.decra...@orange.com>,
Clarence Filsfils <cfils...@cisco.com>
<mailto:cfils...@cisco.com>, "Stefano Previdi"
<stef...@previdi.net> <mailto:stef...@previdi.net>, Rob Shakir
<ro...@google.com> <mailto:ro...@google.com>, "Stephane Litkowski"
<stephane.litkow...@orange.com>
<mailto:stephane.litkow...@orange.com>



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 attools.ietf.org  
<http://tools.ietf.org>.

The IETF Secretariat



___
spring mailing list
spring@ietf.org <mailto: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] I-D Action: draft-ietf-spring-segment-routing-mpls-12.txt

[Ahmed Bashandy (bashandy)]

Hi Alvaro

sorry for the late reply.

I am including the questions and comments in the link [1] and the reply 
to each one of them

See "Ahmed" underneath each question and comment



Q1. Why is this document on the Standards Track? From the Introduction: 
“This drafts describes how Segment Routing operates on top of the MPLS 
data plane.”  Describes, yes.  On the other hand, the Shepherd’s 
write-up says that it “specifies the generic functions of the 
architecture” – I don’t see a specification, just a description.  As 
such, I think this document should be Informational.


This document specifies concepts and externally visible behaviors such as
- Specifies what "MPLS Instantiation of Segment Routing" means
- Specifies the rules governing the value of the local label 
corresponding to a SID

- Specifies the rules governing the SRGB and and SRLB
- Specifies what to do when a router violates the rules governing the SRGB
- Defines and addresses incoming label collision
- Specifies rules governing redistributing prefixes that have prefix-SIDs
- Defines and addresses Outgoing Label Collision
- details for the forwarding behavior including what to do when some or 
all next-hops are not SR capable


Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one 
with any real content…but there are only a couple of things in it that 
are not in the Architecture document: the introduction of the SRLB, and 
some words about the index – both of which should be really explained in 
the Architecture document, and not here.  I wonder what the value of 
publishing this document really is.  What long-term archival value does 
it provide?

Ahmed:
This question is answered within the reply to Q1


Q3. I also have to wonder about the IPR declared for this document. If 
most of the information here is already defined, described or specified 
in draft-ietf-spring-segment-routing, should the IPR declaration apply 
to that document as well (or maybe instead of this one)?  It is not the 
IETF’s role (including the WG) to discuss whether a piece of IPR is 
valid or not – I just want to make sure the disclosures apply to the 
right document.

Ahmed:
I believe we made all the relevant IPR declarations. But if you think 
that some IPR applicable to draft-ietf-spring-segment-routing are also 
applicable to this draft we will make these declarations also towards 
this draft



M1. Section 2. (MPLS Instantiation of Segment Routing) explains how “in 
the MPLS instantiation, the SID values are allocated within a reduced 
20-bit space out of the 32-bit SID space.”  However, I couldn’t find 
where draft-ietf-spring-segment-routing defines the SID space as using 
32 bits (or any other length).  In fact, the closest that document comes 
is when it defines an SID and mentions “Examples of SIDs are: an MPLS 
label, an index value in an MPLS label space, an IPv6 address.”   I’m 
assuming the “32-bit SID space” comes from the fact that the extensions 
define an SID of that length.  All this is to say that as you describe 
how SR operates in the MPLS dataplane, do so not explicitly depending on 
the implementation of the extensions (which in fact seem to already 
account for different lengths).

Ahmed:
this new version (version 12) gives extensive and specific details about 
how to calculate the local and outgoing label  given the SID index


M2.1. “The notion of indexed global segment, defined in 
[I-D.ietf-spring-segment-routing]…”  That document doesn’t properly 
define the concept/use of the index.  There are several mentions in this 
document that I think rely on a proper definition/discussion of the concept.

Ahmed
the new version (version 12) clearly specifies the use of the index and 
how it is translated to local and outgoing labels


M2.2. The concept of an SRLB is not defined in the Architecture document either.
Ahmed:
Addressed in this version (version 12)


M3.1. [minor] I hope to see an explanation of the “[SRGB(next_hop)+index]” 
notation.
Ahmed
This version clearly addresses this part in section 2.4 by specifying the 
structure of SRGB and how to calculate the label given the SRGB ranges

M3.2. What is a “valid SRGB”?  I don’t think the validity of the SRGB is 
described in the Architecture document.
Ahmed
This version clearly specifies the rules governing the SRGB and specifies what 
other routers do when receiving SRGB advertisements that do not conform to 
these rules


M3.3. I’m assuming that once the “next-hop MUST be considered as not 
supporting” then the packets are dropped, right?
Ahmed
This version clearly specifies the forwarding behavior in section 2.10 and what 
to do when the next-hop does not support segment routing


M3.4. [Maybe I’m missing something obvious here.]  Going back to the validity 
of the SRGB advertised by a specific node, shouldn’t the ingress node verify 
that before imposing a path that will fail?  But I couldn’t find anything in 
the Architecture document that talks about the ingress 

Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

[Ahmed Bashandy (bashandy)]

Les replied to that on the thread "[spring] AD Review of 
draft-ietf-spring-segment-routing-12"


So Les and I are still working to resolve some overlap between 
architecture document and sr mpls document and we hope to have new 
versions soon.


Ahmed


On 11/30/2017 2:26 PM, Alvaro Retana wrote:

Ahmed:

Hi!

It’s been almost a month, and I haven’t seen a reply from you.

I will send the document back to the WG by the end of this week.

Thanks!

Alvaro.

On November 2, 2017 at 6:49:10 PM, Alvaro Retana 
(aretana.i...@gmail.com <mailto:aretana.i...@gmail.com>) wrote:


On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) 
(basha...@cisco.com <mailto:basha...@cisco.com> ) wrote:


Ahmed:

Hi!  How are you?

...

The main questions/concerns that I have related to this document is 
not just for the authors, but for the Shepherd and the Chairs too.


Q1. Why is this document on the Standards Track? From the 
Introduction: “This drafts describes how Segment Routing operates on 
top of the MPLS data plane.”  Describes, yes.  On the other hand, 
the Shepherd’s write-up says that it “specifies the generic 
functions of the architecture” – I don’t see a specification, just a 
description.  As such, I think this document should be Informational.


#Ahmed: The new version of the draft specifies many things that are 
applicable to instantiation of SR over MPLS


I’ll take your answer as confirming that the old version (-10) wasn’t 
really specifying anything.


For this new version (-11), can you please be specific on what these 
“many things” are?


I see some new Normative Language in the new 2.x sub-sections.  I 
have some specific comments on that:


Q1.A. Section 2.2. (SID Representation in the MPLS Forwarding Plane):

The MCC MUST ensure that any label value corresponding to any SID it
installs in the forwarding plane follows the following rules:

o  The label value MUST be unique within the router on which the MCC
   is running. i.e. the label MUST only be used to represent the SID.

o  The label value MUST NOT be identical to or within the range of
   any reserved label value or range [reserved-MPLS  
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-11#ref-reserved-MPLS>],
 respectively.


These seem to be new requirements for the MCCs. Given that the protocol extensions 
(and LDP) are defined (in Section 2) as MCCs, how are they supposed to follow these 
rules, specially the first one? As far as I can tell, the IGP extensions (for 
example) can carry Label/SID information from an advertising node, so I don’t know 
how a local MCC (remote to that advertising node, which is locally "installing 
forwarding entries in the MPLS data plane”) can guarantee what the label is used for 
(“only used to represent the SID”). Maybe I’m missing something and this is already 
specified somewhere else…??
The second rule is just what the MPLS Architecture already specifies, 
no nothing new, right? BTW, the link in the reserved-MPLS reference 
doesn’t work — a better reference might be rfc3032 or rfc7274.



Q1.B. Section 2.3. (Segment Routing Global Block and Local Block):

The following rules apply to the list of MPLS ranges representing the
SRGB

o  The list of label ranges MUST only be used to instantiate global
   SIDs into the MPLS forwarding plane

o  Every range in the list of ranges specifying the SRGB MUST NOT
   cover or overlap with a reserved label value or range [reserved-
   MPLS], respectively.
  . . .
Just like SRGB, the SRLB need not be a single
contiguous range of label, except the SRGB MUST only be used to
instantiate global SIDs into the MPLS forwarding plane.

The first rule (and the text below them) points to the global nature 
of the SR *global* Block. The architecture document already says that 
"In SR-MPLS, SRGB is a local property of a node and identifies the 
set of local labels reserved for global segments.” Nothing new 
specified here.
 

   
Q1.C. Section2.4. (Mapping a SID Index to an MPLS label) introduces an algorithm to calculate the label value.  Note that the architecture document now includes an algorithm (in Section 3.1.2) as well — the algorithm in this document doesn’t look to be the same, but even if it is, it would be confusing to specify the same thing in two places.
   
   
   
Q1.D. The rest of the sub-sections seem to rehash forwarding behaviors, which, because of the fact that the MPLS architecture is not changing, seem to add nothing interesting or important to this document.
   


Having said all that, I still don’t see a clear justification for this document 
to be in the Standards Track.
   


Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only 
one with any real content

Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

[Ahmed Bashandy (bashandy)]

I just checked the IPR section in ietf.org. The IPR disclosure for this 
draft can be found in

https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-spring-segment-routing-mpls=draft==

Thanks

Ahmed

On 10/30/2017 11:12 AM, Ahmed Bashandy (bashandy) wrote:


Sorry for the late reply and thanks a lot for the thorough review.

We have just uploaded version 11 of the draft.

See replies inline “#Ahmed” to your comments

Thanks

Ahmed

*From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Alvaro 
Retana (aretana)

*Sent:* Wednesday, August 23, 2017 7:39 PM
*To:* draft-ietf-spring-segment-routing-m...@ietf.org 
<mailto:draft-ietf-spring-segment-routing-m...@ietf.org>
*Cc:* spring-cha...@ietf.org <mailto:spring-cha...@ietf.org>; 
spring@ietf.org <mailto:spring@ietf.org>; Martin Vigoureux 
<martin.vigour...@nokia.com <mailto:martin.vigour...@nokia.com>>

*Subject:* [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

Dear authors:

I just finished reading this document.  Please take a look at my 
comments below.


The main questions/concerns that I have related to this document is 
not just for the authors, but for the Shepherd and the Chairs too.


Q1. Why is this document on the Standards Track? From the 
Introduction: “This drafts describes how Segment Routing operates on 
top of the MPLS data plane.”  Describes, yes.  On the other hand, the 
Shepherd’s write-up says that it “specifies the generic functions of 
the architecture” – I don’t see a specification, just a description.  
As such, I think this document should be Informational.


#Ahmed: The new version of the draft specifies many things that are 
applicable to instantiation of SR over MPLS


Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one 
with any real content…but there are only a couple of things in it that 
are not in the Architecture document: the introduction of the SRLB, 
and some words about the index – both of which should be really 
explained in the Architecture document, and not here.  I wonder what 
the value of publishing this document really is.  What long-term 
archival value does it provide?


#Ahmed: The long term plan is to move details of MPLS-specific 
specifications to this document and keep the architecture document 
more general


Q3. I also have to wonder about the IPR declared for this document.  
If most of the information here is already defined, described or 
specified in draft-ietf-spring-segment-routing, should the IPR 
declaration apply to that document as well (or maybe instead of this 
one)?  It is not the IETF’s role (including the WG) to discuss whether 
a piece of IPR is valid or not – I just want to make sure the 
disclosures apply to the right document.


#Ahmed: We will make sure that all IPR is declared

I didn’t find a discussion on the list about any of these points.

Thanks!

Alvaro.

Major

M1. Section 2. (MPLS Instantiation of Segment Routing) explains how 
“in the MPLS instantiation, the SID values are allocated within a 
reduced 20-bit space out of the 32-bit SID space.” However, I couldn’t 
find where draft-ietf-spring-segment-routing defines the SID space as 
using 32 bits (or any other length).  In fact, the closest that 
document comes is when it defines an SID and mentions “Examples of 
SIDs are: an MPLS label, an index value in an MPLS label space, an 
IPv6 address.”   I’m assuming the “32-bit SID space” comes from the 
fact that the extensions define an SID of that length.  All this is to 
say that as you describe how SR operates in the MPLS dataplane, do so 
not explicitly depending on the implementation of the extensions 
(which in fact seem to already account for different lengths).


#Ahmed: The part that talks about the reduced 20 bit spaced has been 
removed. Instead the beginning of section 2.2 clearly specifies that a 
SID is an MPLS label and if it is an index it should be inside the 
SRGB. Section 2.4 specifies how to translate the Index to a label 
within the SRGB


M2. [I mentioned these issues in the review of 
draft-ietf-spring-segment-routing as well.]


M2.1. “The notion of indexed global segment, defined in 
[I-D.ietf-spring-segment-routing]…”  That document doesn’t properly 
define the concept/use of the index.  There are several mentions in 
this document that I think rely on a proper definition/discussion of 
the concept.


#Ahmed: Section 2.4 specify how to translate the Index to a label 
within the SRGB. The architecture draft defines the concept of an index


M2.2. The concept of an SRLB is not defined in the Architecture 
document either.


#Ahmed: The latest version of the architecture document defines the SRLB

M3. Still in Section 2, from this text:

  * When different SRGBs are used, the outgoing label value is set

 as: [SRGB(next_hop)+index].  If the index can't be applied to

 the SRGB (i.e.: if the index points outside the SRGB of the

next-hop or the next-hop h

Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

[Ahmed Bashandy (bashandy)]

Sorry for the late reply and thanks a lot for the thorough review.

We have just uploaded version 11 of the draft.

See replies inline “#Ahmed” to your comments

Thanks

Ahmed



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alvaro Retana 
(aretana)
Sent: Wednesday, August 23, 2017 7:39 PM
To: 
draft-ietf-spring-segment-routing-m...@ietf.org
Cc: spring-cha...@ietf.org; 
spring@ietf.org; Martin Vigoureux 
>
Subject: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

Dear authors:

I just finished reading this document.  Please take a look at my comments below.

The main questions/concerns that I have related to this document is not just 
for the authors, but for the Shepherd and the Chairs too.

Q1. Why is this document on the Standards Track? From the Introduction: “This 
drafts describes how Segment Routing operates on top of the MPLS data plane.”  
Describes, yes.  On the other hand, the Shepherd’s write-up says that it 
“specifies the generic functions of the architecture” – I don’t see a 
specification, just a description.  As such, I think this document should be 
Informational.
#Ahmed: The new version of the draft specifies many things that are applicable 
to instantiation of SR over MPLS

Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one with any 
real content…but there are only a couple of things in it that are not in the 
Architecture document: the introduction of the SRLB, and some words about the 
index – both of which should be really explained in the Architecture document, 
and not here.  I wonder what the value of publishing this document really is.  
What long-term archival value does it provide?
#Ahmed: The long term plan is to move details of MPLS-specific specifications 
to this document and keep the architecture document more general

Q3. I also have to wonder about the IPR declared for this document.  If most of 
the information here is already defined, described or specified in 
draft-ietf-spring-segment-routing, should the IPR declaration apply to that 
document as well (or maybe instead of this one)?  It is not the IETF’s role 
(including the WG) to discuss whether a piece of IPR is valid or not – I just 
want to make sure the disclosures apply to the right document.
#Ahmed: We will make sure that all IPR is declared


I didn’t find a discussion on the list about any of these points.

Thanks!

Alvaro.


Major

M1. Section 2. (MPLS Instantiation of Segment Routing) explains how “in the 
MPLS instantiation, the SID values are allocated within a reduced 20-bit space 
out of the 32-bit SID space.”  However, I couldn’t find where 
draft-ietf-spring-segment-routing defines the SID space as using 32 bits (or 
any other length).  In fact, the closest that document comes is when it defines 
an SID and mentions “Examples of SIDs are: an MPLS label, an index value in an 
MPLS label space, an IPv6 address.”   I’m assuming the “32-bit SID space” comes 
from the fact that the extensions define an SID of that length.  All this is to 
say that as you describe how SR operates in the MPLS dataplane, do so not 
explicitly depending on the implementation of the extensions (which in fact 
seem to already account for different lengths).
#Ahmed: The part that talks about the reduced 20 bit spaced has been removed. 
Instead the beginning of section 2.2 clearly specifies that a SID is an MPLS 
label and if it is an index it should be inside the SRGB. Section 2.4 specifies 
how to translate the Index to a label within the SRGB

M2. [I mentioned these issues in the review of 
draft-ietf-spring-segment-routing as well.]

M2.1. “The notion of indexed global segment, defined in 
[I-D.ietf-spring-segment-routing]…”  That document doesn’t properly define the 
concept/use of the index.  There are several mentions in this document that I 
think rely on a proper definition/discussion of the concept.
#Ahmed: Section 2.4 specify how to translate the Index to a label within the 
SRGB. The architecture draft defines the concept of an index

M2.2. The concept of an SRLB is not defined in the Architecture document either.
#Ahmed: The latest version of the architecture document defines the SRLB

M3. Still in Section 2, from this text:

  *  When different SRGBs are used, the outgoing label value is set
 as: [SRGB(next_hop)+index].  If the index can't be applied to
 the SRGB (i.e.: if the index points outside the SRGB of the
 next-hop or the next-hop has not advertised a valid SRGB), then
 no outgoing label value can be computed and the next-hop MUST
 be considered as not supporting the MPLS operations for that
 particular SID.

…several questions/comments…

M3.1. [minor] I hope to see an explanation of the “[SRGB(next_hop)+index]” 
notation.
#Ahmed: 

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Ahmed Bashandy (bashandy)]

Hi

Also  support as a co-author

Ahmed

On 1/30/2017 12:58 AM, Martin Horneffer wrote:

Hello,

support from me as co-author and operator.

Bets regards, Martin


Am 27.01.17 um 12:05 schrieb Martin Vigoureux:


Hello Working Group,

This email starts a 2-week Working Group Last Call on 
draft-ietf-spring-segment-routing-mpls-06 [1].


¤ Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than the
*12th of February*.
Note that this is *not only* a call for comments on the document; it 
is also a call for support (or not) to publish this document as a 
Proposed Standard RFC.


¤ We have already polled for IPR knowledge on this document and all 
Authors have replied.

IPR exists against this document and has been disclosed [2].

Thank you

M

---
[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring-segment-routing-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] IPR for draft‐ietf-spring-segment‐routing-mpls prior to WGLC

[Ahmed Bashandy (bashandy)]

I’m not aware of any IPR that hasn’t been disclosed already.

Thanks

Ahmed

On 9/9/2016 4:57 AM, Martin Vigoureux wrote:

Authors and Contributors,

it seems that we are missing answers to the IPR question from a good 
number of people:


Authors: Clarence, Ahmed, Martin, and Edward
Contributors: Igor and Saku

Please do respond. We need this to move forward.

Thanks
-m

Le 08/08/2016 13:10, stephane.litkow...@orange.com a écrit :

Hi,

I'm not aware of any IPR for this doc.

Brgds,

Stephane

-Original Message-
From: John G.Scudder [mailto:j...@juniper.net]
Sent: Sunday, July 24, 2016 14:52
To: draft-ietf-spring-segment-routing-m...@ietf.org
Cc: spring@ietf.org
Subject: IPR for draft‐ietf-spring-segment‐routing-mpls prior to WGLC

Dear Authors:

As we discussed at the SPRING meeting, working group last call has 
been requested for draft‐ietf-spring-segment‐routing-mpls. Before we 
begin the WGLC, please indicate whether you are aware of any relevant 
IPR and if so, whether it has been disclosed. (Please do this even if 
you've done it before, thanks for your help.) Please cc the WG in 
your reply.


As soon as this has been collected from all authors, we'll start the 
WGLC.


Thanks,

--Bruno and John

_ 



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

Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call

[Ahmed Bashandy (bashandy)]

Support. Very much needed

Ahmed

On 4/14/2016 12:50 AM, bruno.decra...@orange.com wrote:

Dear WG,

As we discussed at our meeting last week, working group adoption has been 
requested for draft-ginsberg-spring-conflict-resolution.
Please reply to the list with your comments, including although not limited to 
whether or not you support adoption.

Thanks,

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

Re: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop

[Ahmed Bashandy (bashandy)]

Hi Robin

The mapping server is already implemented. And it is not that complex at all

As for the support of inter-AS option "C", there are two solutions
(1) "draft-filsfils-spring-sr-recursing-info-01" provides a way to use 
the prefix-SID of one address for another one. So refering to the second 
figure in the your draft "draft-li-spring-compare-sr-ldp-rsvpte-00", 
ASBR12 can  inject the IP addresses of "PE21" and "PE22" in the IGP of 
AS1 and use the IP address of ASBR11 itself as the "Recursing SID Address".
(2) "draft-ietf-spring-segment-routing-ldp-interop" suggests using 
BGP-LU to distribute the remote domain information as Jon Mitchell 
mention in his email. At the first glance, it may seem like an issue for 
some platforms. However, as it is mentioned in 
"draft-bashandy-rtgwg-bgp-pic-02" which was presented in the last IETF, 
it is actually very easy to flatten a 2 level recursion into a single 
level of recursion, thereby supporting any hardware capability


Thanks

Ahmed



On 11/2/2015 5:21 PM, Lizhenbin wrote:


Hi Folks,

I proposed my concern on the implementation of interoperability 
between LDP and SR again in IETF. I also would like to remind you of 
my draft again:


https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-00

In this draft I explained the possible challenges of SR comparing LDP. 
And in sec 6 I summary the possible challenge of Interoperability 
between SR and LDP/RSVP-TE. Until now I believe that there will be 
much challege for the implementation. In fact in order to solve the 
possbile issue I mentioned in the draft, the mapping server has been 
introduced. Is it some central-control based solution in the IGP/LDP 
distributed environment? I worried that there still more issues which 
have to be solved and propose great challenge for the implementor on 
the feature and when new mechanisms are introduced they will propose 
new challenges again. If so, this may be nightmare for the developer 
of the feature. Hope if there were the implementation the 
implementation report on 
draft-ietf-spring-segment-routing-ldp-interop-00 can be publised 
accomanying the draft to demonstrate what can be done and maye what 
can not be done. This will be much helpful to the implementors and 
operators to consider their possible choice to cope with this interop 
issue: take the challenge, leave it or replace the LDP network with SR 
all at once without introducing the interoperability issue.


Best Regards,

Zhenbin(Robin)



___
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] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-02.txt

[Ahmed Bashandy (bashandy)]

Thanks a lot Les for the elaborate explanation

One small addition to what Les mentioned. The functionality proposed by 
the draft can be achieved by having a base prefix-SID index and then 
configuring an offset (instead of an SRGB) for each topology/algorithm 
pair from that base prefix-SID index value. Based on the configured 
offset, the router would then calculate the corresponding prefix-SID 
index for each topology/algorithm pair and advertise it using existing 
mechanisms


Note that the above is NOT a suggestion to use the offset mechanism to 
configure prefix-SID indices. The objective is to show that the draft 
does not offer enough benefits to warrant all the questions marks that 
are outlined in Les's email.


Thanks

Ahmed

On 11/9/2015 1:11 AM, Les Ginsberg (ginsberg) wrote:

Chris -

I have a number of questions - but in order to properly frame them I need to 
recount some history - please bear with me.

In the very early days of SR there was a proposal to reserve a fixed label 
range on all routers (16000 - 23999) for the use of SR. This seemed workable 
but there was concern that the same range would not be available on all routers 
so the SR community agreed that we needed to allow the advertisement of a 
different SRGB range on each SR capable router.

Then, another concern was raised that a single contiguous range large enough to 
meet the SR requirements might not be available on all routers and therefore we 
needed to support the advertisement of multiple SRGB ranges from a given node. 
This capability has been added - though it has also raised other concerns 
regarding how many ranges might be enough and how to deal with inconsistencies 
(overlaps) in the advertised ranges should some error occur.

Now, in support of multiple algorithms/topologies, this draft proposes that 
algorithm/topology specific SRGBs be advertised - and that to fully get the 
benefits of consistent SID assignment for the same prefix across 
algorithms/topologies (the major goal of this draft) that all routers be able 
to support identical ranges for each algorithm/topology. (Section 5 goes into 
this in detail) - and to be able to allocate new ranges for newly configured 
algorithms/topologies on demand.  Section 6 goes on to suggest that it would be 
a wonderful goal if all routers could assign the same base label/range to each 
algorithm/topology so that the labels could be derived algorithmically (though 
you admit this may not always be possible).

My first question is how do you reconcile this requirement for consistency on 
all nodes with the earlier decisions to support inconsistency as regards SRGB 
base values/range sizes?

My second question is associated with the assumption of a single "node_index" per node. I 
for one would be delighted if we could get agreement on using a single host address/node (or at 
least one per AF) for all traffic to that node. But this does not meet the deployment requirements 
in all cases and so we support multiple "node_indeces" for a given node. This means that 
we do not map SIDs to nodes - we map SIDs to prefixes. So it is conceptually more straightforward 
and less problematic to configure SIDs for prefix ranges. This is in fact how SRMS advertisements 
are constructed i.e.

   (Prefix/Prefix length, Starting SID, Range)

How would you propose to incorporate this style of SID assignment into your 
algorithms? Do you assume a maximum number of node-sids required for every node 
in the network and require the range for each algorithm/topology be sized large 
enough for the worst case? This seems potentially wasteful - especially if a 
deployment chooses to use a particular address for a topology as a traffic 
differentiator.

My third question relates to the algorithm/topology independence of the SID 
assignment that you propose. Throughout the document you assume that you have a 
single SID for a given prefix and you simply add the appropriate 
algorithm/topology specific SRGB base value to this SID to derive the 
forwarding label. However, current protocol advertisements for SIDs include 
both algorithm and topology as context for the SID. This reflects the current 
SR architecture which has been defined with algorithm/topology as an explicit 
context for a SID. Your proposal fundamentally changes this and therefore all 
existing encodings of SID advertisements (prefix reachability, SRGB, SRMS 
advertisements) would have to be changed in a non-backwards compatible way in 
order to support your proposal.  Other than definition of a new SRGB 
advertisement, you do not discuss this in the draft. How do you intend to 
address this major issue?

Les



-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Monday, October 05, 2015 12:31 PM
To: spring@ietf.org
Subject: [spring] FW: New Version Notification for draft-bowers-spring-adv-
per-algorithm-label-blocks-02.txt

SPRING WG,

There was quite a lot of 

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

[Ahmed Bashandy (bashandy)]

if I understand you reply to Peter correctly, does this means that 
multi-prefix SID should not be leaked outside its originating area?


Ahmed


On 10/8/2015 6:11 AM, Pushpasis Sarkar wrote:

Hi Peter,




On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:


how do you envision to find out the node originating a prefix in case of
inter-area prefixe?

[Pushpasis] The ABR on the originating area/level should be able to detect the 
anomaly like other nodes in the same area/level and block re-advertisement.

Thanks
-Pushpasis
___
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] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

[Ahmed Bashandy (bashandy)]

Support as an author
Not aware of undisclosed IPR

Ahmed

On 9/23/2015 9:59 AM, Henderickx, Wim (Wim) wrote:

Support and not aware of IPR related to this draft




On 22/07/15 15:17, "mpls on behalf of John G.Scudder"  wrote:


Dear WG,

As we discussed at our meeting yesterday, working group adoption has been 
requested for draft-filsfils-spring-segment-routing-ldp-interop. Please reply 
to the list with your comments, including although not limited to whether or 
not you support adoption. Non-authors are especially encouraged to comment.

In consideration of the fact that a number of WG calls are going on 
concurrently, we will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if so, whether it 
has been disclosed. Also, the length of the author list for this document greatly exceeds 
the maximum recommended. Assuming the document is adopted, the authors should be prepared 
to correct this when submitting as a WG document, ideally by reducing the list to simply 
the active editor(s) and making use of the "contributors" section for the full 
list.

Thanks,

--Bruno and John

P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to.
___
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] draft-ietf-spring-segment-routing-05

[Ahmed Bashandy (bashandy)]

Totally agree

We expect lots of applications and use cases to come.
Let's close this document

Ahmed

On 9/25/2015 1:22 AM, Rob Shakir wrote:

On 24 September 2015 at 09:09:00, Anil Kumar S N (VRP Network BL) 
(anil...@huawei.com) wrote:

Hi Rob,
  
Thanks for reverting back the mail.
  
If there is a desire to control traffic flows on individual bundle interface,

information about each of the bundle members interface is required to be flooded
using IGP extension. Segment routing framework is generic and flexible enough 
to handle
this.
IGP extension need to support it.
[…snip…]

Right - but this draft does not seek to catalogue every possible use of SR - 
since it could not possibly do this (given that some will be invented in the 
future). The examples within it give sufficient motivation for the types of SID 
that are defined which, IMHO, is their intention.

I think it would be best to finalise this document with what is there. Perhaps 
my co-authors will disagree.

r.

___
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] Modeling SRGB configuration for draft-ietf-spring-sr-yang

[Ahmed Bashandy (bashandy)]

One of the objective of the YANG Model is to manage devices. Hence the 
flexibility of having a separate SRGB per protocol is necessary, at 
least for operational reasons



Ahmed

On 7/29/2015 2:01 PM, Les Ginsberg (ginsberg) wrote:


Stephane --

What is the requirement to have a per-protocol SRGB config?

This makes no sense to me operationally or architecturally.

(I am not talking about what may or may not have been implemented by 
vendors -- the YANG model should be architecturally correct)


   Les

*From:*stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]

*Sent:* Wednesday, July 29, 2015 5:11 AM
*To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha 
(Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); 
Pushpasis Sarkar (psar...@juniper.net); Hannes Gredler 
(han...@juniper.net)
*Subject:* RE: [spring] Modeling SRGB configuration for 
draft-ietf-spring-sr-yang


Hi all,

What if we keep the SRGB block config in segment-routing global 
module, and if we allow for YANG configuration of carving this block 
inside each protocol (maybe as a feature) ?


Stephane

*From:*Uma Chunduri [mailto:uma.chund...@ericsson.com]
*Sent:* Friday, July 24, 2015 16:59
*To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); 
LITKOWSKI Stephane SCE/IBNF; spring@ietf.org mailto:spring@ietf.org
*Subject:* RE: [spring] Modeling SRGB configuration for 
draft-ietf-spring-sr-yang


Suggesting that the forwarding instruction (AKA label)  needs to be different depending on what 
protocol provided


the instruction is completely unnecessary -- it simply wastes label space.

[Uma]: Les, No - I never suggested anything like that.

SRGB for a routing instance to be advertised should be part of the 
routing instance provisioning as far as the yang model is concerned.


Carving out the label space for SR is a local matter and agree, of 
course, this  can be done in so many ways through CLI, dynamically, 
statically etc...


--

Uma C.

_
  
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

Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc

[Ahmed Bashandy (bashandy)]

strongly support

Thanks

Ahmed

On 7/22/2015 6:15 AM, John G.Scudder wrote:

Dear WG,

As we discussed at our meeting yesterday, working group adoption has been 
requested for draft-filsfils-spring-segment-routing-msdc. Please reply to the 
list with your comments, including although not limited to whether or not you 
support adoption. Non-authors are especially encouraged to comment.

In consideration of the fact that a number of WG calls are going on 
concurrently, we will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if so, whether it 
has been disclosed. Also, the length of the author list for this document greatly exceeds 
the maximum recommended. Assuming the document is adopted, the authors should be prepared 
to correct this when submitting as a WG document, ideally by reducing the list to simply 
the active editor(s) and making use of the contributors section for the full 
list.

Thanks,

--Bruno and John

___
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