Re: [spring] IPR poll on draft-ietf-mpls-spring-lsp-ping

[Faisal Iqbal (faiqbal)]

Hi Loa,
I'm not aware of any IPR applying to draft-ietf-mpls-spring-lsp-ping.

Regards,
Faisal


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Loa Andersson
Sent: Monday, June 5, 2017 3:39 AM
To: m...@ietf.org
Cc: spring@ietf.org; mpls-cha...@ietf.org; 
draft-ietf-mpls-spring-lsp-p...@ietf.org
Subject: [spring] IPR poll on draft-ietf-mpls-spring-lsp-ping

Working Group, authors,

We have started to prepare the the draft-ietf-mpls-spring-lsp-ping for wglc, 
prior to the wglc we need to do an IPR poll.

This mail starts this IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-spring-lsp-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

No IPR disclosures have been submitted directly on draft-ietf-mpls- 
spring-lsp-ping or the individual document it replaced.

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the MPLS WG mailing list.* The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the MPLS WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Since this document might be of interest for the SPRING wg, it has been copied 
to the SPRING wg mailing list.

/Loa
mpls wg co-chair
-- 


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

___
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] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Stefano Previdi (sprevidi)]

> On Jun 12, 2017, at 4:05 PM, bruno.decra...@orange.com wrote:
> 
> Hi Stefano,
> 
>> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: 
>> Monday, June 12, 2017 3:52 PM
>> 
>> Hi Rob,
>> 
>> sorry for the mess. I’m afraid, the problem has been poorly described.
>> 
>> We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
>> proposing the
>> removal of it.
>> 
>> What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
>> been defined in
>> both isis and ospf protocols and for which, apparently, nobody has found yet 
>> any use.
> 
> In order to clarify, could you provide the precise list/set of those subTLVs 
> which are proposed to be removed? for both IS-IS and OSPF.


I’d expect anyone to make the effort to go read the isis and ospf specs. 
Nevertheless, here are the set of subTLVs in ISIS in the form of 

2.4.7.  ERO Metric sub-TLV
2.4.8.  IPv4 ERO subTLV
2.4.9.  IPv6 ERO subTLV
2.4.10. Unnumbered Interface ID ERO subTLV
2.4.11. IPv4 Backup ERO subTLV
2.4.12. IPv6 Backup ERO subTLV
2.4.13. Unnumbered Interface ID Backup ERO subTLV

You’ll find the same subTLVs in ospf and ospfv3 drafts.

Note also that you have the equivalent TLVs defined in bgp-ls by 
draft-ietf-idr-bgp-ls-segment-routing-ext.

s.


> 
> Thanks
> --Bruno
> 
>> Can we try to shutdown the unnecessary noise and confusion ?
>> 
>> Thanks.
>> s.
>> 
>> 
>>> On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:
>>> 
>>> Bruno, SPRING,
>>> 
>>> I am aware of at least one implementation that makes heavy use of Binding 
>>> SIDs, so I do
>> not think that this is something that we can remove from the protocol 
>> specification.
>>> It seems to me that we have a number of cases that continue to exist that 
>>> make it useful to
>> have them specified, particularly:
>>> • Binding of a SID to a deeper label stack to prevent there being large 
>>> label stacks
>> required on ingress. This is required due to limited push depth, and limited 
>> readable label
>> depths for hashing.
>>> • Re-use of some other protocol's or network's forwarding path by a 
>>> device that is
>> imposing an SR label stack.
>>> There is not an alternative construct that can be used for this purpose, so 
>>> we should not
>> remove it.
>>> 
>>> In both of these cases there seems, to me, to be a use case for having the 
>>> information in
>> the IGP in the case that an implementation computes TE paths using cSPF, 
>> having binding SID
>> information available to it (along with the ERO) enables it to reduce the 
>> label stack depth by
>> finding binding SIDs that follow the same path as the computed ERO. Without 
>> the ERO
>> (which might not be an RSVP-TE ERO, but I believe that it how it was first 
>> envisaged) how can
>> the head-end of an TE path know what path the advertised Binding SID takes? 
>> It's fine to
>> punt this and say "the PCE in the sky will know" - however, I believe 
>> SPRING's charter
>> doesn't limit the technology to only centralised computation of paths.
>>> 
>>> I don't believe current demand for this is a good reason to remove it from 
>>> the protocol
>> specification - it is still somewhat early days for folks deploying TE based 
>> on SR - where I
>> think the Binding SID concept is most important.
>>> 
>>> r.
>>> 
>>> On Mon, 12 Jun 2017 at 05:50  wrote:
>>> Hello SPRING WG,
>>> 
>>> I'd like to encourage discussion on this thread.
>>> 
>>> The related questions seem to be:
>>> - Binding SIDs:
>>>-  Is there any implementation?
>>>- Is it useful?
>>>- Does it need to be specified?
>>> 
>>> - Binding SIDs advertised in IGP:
>>>-  Is there any implementation?
>>> - Is it useful?
>>>- Does it need to be specified?
>>> 
>>> As of today, there seem to be multiple SPRING (related) document that make 
>>> reference
>> (define/use) to the Binding SIDs. e.g.
>>> - architecture 
>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-
>> 3.5.2
>>> - MPLS instantiation 
>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-
>> 08#section-2
>>> - non-protected paths 
>>> https://tools.ietf.org/html/draft-litkowski-spring-non-protected-
>> paths-01#section-3.3
>>> - SR policies: 
>>> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-
>> 00#section-7
>>> 
>>> 
>>> However, it also seems a priori possible to define Binding SIDs and not 
>>> advertised them in
>> the IGP. (e.g. by keeping them local to the PCE)
>>> 
>>> On a side note, if the Binding SIDs are removed from the IGP, do they need 
>>> to be removed
>> from the BGP-LS extensions? [+IDR chairs]
>>> 
>>> Thanks,
>>> Regards,
>>> --Bruno
>>> 
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
 Sent: Monday, June 12, 2017 10:18 AM
 To: OSPF WG List; spring@ietf.org; isis...@ietf.org
 Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Peter Psenak]

Stefano, Rob,

the question is about the "usage of the SID/Label Binding TLV", not 
about the Binding SID concept. I don't know how to better describe the 
problem.


In ISIS SR draft SID/Label Binding TLV has two functions:

1. Advertise the SID/Label binding to a FEC
2. SRMS advertisements

In OSPF SID/Label Binding TLV has only one function:

1. Advertise the SID/Label binding to a FEC

The question is whether we need the function (1) at all in IGP SR drafts.

thanks,
Peter



On 12/06/17 15:52 , Stefano Previdi (sprevidi) wrote:

Hi Rob,

sorry for the mess. I’m afraid, the problem has been poorly described.

We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
proposing the removal of it.

What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
been defined in both isis and ospf protocols and for which, apparently, nobody 
has found yet any use.

Can we try to shutdown the unnecessary noise and confusion ?

Thanks.
s.



On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:

Bruno, SPRING,

I am aware of at least one implementation that makes heavy use of Binding SIDs, 
so I do not think that this is something that we can remove from the protocol 
specification.
It seems to me that we have a number of cases that continue to exist that make 
it useful to have them specified, particularly:
• Binding of a SID to a deeper label stack to prevent there being large 
label stacks required on ingress. This is required due to limited push depth, 
and limited readable label depths for hashing.
• Re-use of some other protocol's or network's forwarding path by a 
device that is imposing an SR label stack.
There is not an alternative construct that can be used for this purpose, so we 
should not remove it.

In both of these cases there seems, to me, to be a use case for having the information in 
the IGP in the case that an implementation computes TE paths using cSPF, having binding 
SID information available to it (along with the ERO) enables it to reduce the label stack 
depth by finding binding SIDs that follow the same path as the computed ERO. Without the 
ERO (which might not be an RSVP-TE ERO, but I believe that it how it was first envisaged) 
how can the head-end of an TE path know what path the advertised Binding SID takes? It's 
fine to punt this and say "the PCE in the sky will know" - however, I believe 
SPRING's charter doesn't limit the technology to only centralised computation of paths.

I don't believe current demand for this is a good reason to remove it from the 
protocol specification - it is still somewhat early days for folks deploying TE 
based on SR - where I think the Binding SID concept is most important.

r.

On Mon, 12 Jun 2017 at 05:50  wrote:
Hello SPRING WG,

I'd like to encourage discussion on this thread.

The related questions seem to be:
- Binding SIDs:
 -  Is there any implementation?
 - Is it useful?
 - Does it need to be specified?

- Binding SIDs advertised in IGP:
 -  Is there any implementation?
  - Is it useful?
 - Does it need to be specified?

As of today, there seem to be multiple SPRING (related) document that make 
reference (define/use) to the Binding SIDs. e.g.
- architecture 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
- MPLS instantiation 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
- non-protected paths 
https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
- SR policies: 
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7


However, it also seems a priori possible to define Binding SIDs and not 
advertised them in the IGP. (e.g. by keeping them local to the PCE)

On a side note, if the Binding SIDs are removed from the IGP, do they need to 
be removed from the BGP-LS extensions? [+IDR chairs]

Thanks,
Regards,
--Bruno


From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Monday, June 12, 2017 10:18 AM

  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect
  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
  >
  > Hi,
  >
  > I would like to get some feedback on the usage of the SID/Label Binding TLV.
  >
  > Is there any implementation that uses SID/Label Binding TLV for
  > advertising the SID/Label binding to a FEC as specified in section 6 of
  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
  > draft-ietf-isis-segment-routing-extensions-12?
  >
  > If not, do we see this as something we want to preserve in the IGP SR
  > drafts?
  >
  > ISIS uses The SID/Label Binding TLV to advertise
  > prefixes to SID/Label mappings, which is known to be supported by
  > several implementations and that piece 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[bruno.decraene]

Hi Stefano,

> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]  > Sent: Monday, 
> June 12, 2017 3:52 PM
> 
 > Hi Rob,
 > 
 > sorry for the mess. I’m afraid, the problem has been poorly described.
 > 
 > We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
 > proposing the
 > removal of it.
 > 
 > What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
 > been defined in
 > both isis and ospf protocols and for which, apparently, nobody has found yet 
 > any use.

In order to clarify, could you provide the precise list/set of those subTLVs 
which are proposed to be removed? for both IS-IS and OSPF.

Thanks
--Bruno
 
 > Can we try to shutdown the unnecessary noise and confusion ?
 > 
 > Thanks.
 > s.
 > 
 > 
 > > On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:
 > >
 > > Bruno, SPRING,
 > >
 > > I am aware of at least one implementation that makes heavy use of Binding 
 > > SIDs, so I do
 > not think that this is something that we can remove from the protocol 
 > specification.
 > > It seems to me that we have a number of cases that continue to exist that 
 > > make it useful to
 > have them specified, particularly:
 > >• Binding of a SID to a deeper label stack to prevent there being large 
 > > label stacks
 > required on ingress. This is required due to limited push depth, and limited 
 > readable label
 > depths for hashing.
 > >• Re-use of some other protocol's or network's forwarding path by a 
 > > device that is
 > imposing an SR label stack.
 > > There is not an alternative construct that can be used for this purpose, 
 > > so we should not
 > remove it.
 > >
 > > In both of these cases there seems, to me, to be a use case for having the 
 > > information in
 > the IGP in the case that an implementation computes TE paths using cSPF, 
 > having binding SID
 > information available to it (along with the ERO) enables it to reduce the 
 > label stack depth by
 > finding binding SIDs that follow the same path as the computed ERO. Without 
 > the ERO
 > (which might not be an RSVP-TE ERO, but I believe that it how it was first 
 > envisaged) how can
 > the head-end of an TE path know what path the advertised Binding SID takes? 
 > It's fine to
 > punt this and say "the PCE in the sky will know" - however, I believe 
 > SPRING's charter
 > doesn't limit the technology to only centralised computation of paths.
 > >
 > > I don't believe current demand for this is a good reason to remove it from 
 > > the protocol
 > specification - it is still somewhat early days for folks deploying TE based 
 > on SR - where I
 > think the Binding SID concept is most important.
 > >
 > > r.
 > >
 > > On Mon, 12 Jun 2017 at 05:50  wrote:
 > > Hello SPRING WG,
 > >
 > > I'd like to encourage discussion on this thread.
 > >
 > > The related questions seem to be:
 > > - Binding SIDs:
 > > -  Is there any implementation?
 > > - Is it useful?
 > > - Does it need to be specified?
 > >
 > > - Binding SIDs advertised in IGP:
 > > -  Is there any implementation?
 > >  - Is it useful?
 > > - Does it need to be specified?
 > >
 > > As of today, there seem to be multiple SPRING (related) document that make 
 > > reference
 > (define/use) to the Binding SIDs. e.g.
 > > - architecture 
 > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-
 > 3.5.2
 > > - MPLS instantiation 
 > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-
 > 08#section-2
 > > - non-protected paths 
 > > https://tools.ietf.org/html/draft-litkowski-spring-non-protected-
 > paths-01#section-3.3
 > > - SR policies: 
 > > https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-
 > 00#section-7
 > >
 > >
 > > However, it also seems a priori possible to define Binding SIDs and not 
 > > advertised them in
 > the IGP. (e.g. by keeping them local to the PCE)
 > >
 > > On a side note, if the Binding SIDs are removed from the IGP, do they need 
 > > to be removed
 > from the BGP-LS extensions? [+IDR chairs]
 > >
 > > Thanks,
 > > Regards,
 > > --Bruno
 > >
 > > > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
 > > > Sent: Monday, June 12, 2017 10:18 AM
 > >  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
 > >  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
 > >  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions 
 > > (would also
 > effect
 > >  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
 > >  >
 > >  > Hi,
 > >  >
 > >  > I would like to get some feedback on the usage of the SID/Label Binding 
 > > TLV.
 > >  >
 > >  > Is there any implementation that uses SID/Label Binding TLV for
 > >  > advertising the SID/Label binding to a FEC as specified in section 6 of
 > >  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
 > >  > draft-ietf-isis-segment-routing-extensions-12?
 > >  >
 > >  > If not, 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Acee Lindem (acee)]

Hi Bruno,

From: Bruno Decraene 
>
Date: Monday, June 12, 2017 at 9:37 AM
To: Acee Lindem >, 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
 
>,
 
"draft-ietf-isis-segment-routing-extensi...@ietf.org"
 
>
Cc: "spring@ietf.org" 
>, 
"isis...@ietf.org" 
>, OSPF WG List 
>
Subject: RE: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Hi Acee, authors

2 clarification questions inline [Bruno]

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, June 09, 2017 4:46 PM
To: OSPF WG List; spring@ietf.org; 
isis...@ietf.org
Cc: 
draft-ietf-ospf-segment-routing-extensi...@ietf.org
Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Corrected IS-IS WG alias – Please reply to this one.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, June 9, 2017 at 10:42 AM
To: OSPF WG List >, 
"spring@ietf.org" 
>, 
"i...@ietf.org" >
Cc: 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
 
>
Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also effect 
OSPFv3 and IS-IS)

Hi OSPF, ISIS, and SPRING WGs,

As part of the Alia’s AD review, she uncovered the fact that the ERO extensions 
in 6.1 and 6.2 are specified as far as encoding but are not specified as far as 
usage in any IGP or SPRING document. As document shepherd,  my proposal is that 
they simply be removed since they were incorporated as part of a draft merge 
and it appears that no one has implemented them (other than parsing).
[Bruno] Is the option to move those Binding SID IGP extensions in a different 
(WG) document opened/considered? Any opinion on this?
If there is the energy to fully specify usage, than a separate document would 
make sense. I think there is a enough description of the binding SID in 
existing SPRING documents. However, it the ERO that is not specified.


We could also deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV 
registry to delay usage of these code points for some time (or indefinitely ;^).
[Bruno] Are there reasons to make actions to delay/against such usage?
Since these are fully specified in the IGP Extensions, there are probably 
implementations that parse and validate the sub-TLVs.

Thanks,
Acee




Thanks
Regards,
--Bruno

Thanks,
Acee

_

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

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

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

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Stefano Previdi (sprevidi)]

Hi Rob,

sorry for the mess. I’m afraid, the problem has been poorly described.

We’re obviously NOT questioning the use of the Binding SID and we’re NOT 
proposing the removal of it.

What we’re talking about is the set of RSVP-like/ERO-like subTLVs that have 
been defined in both isis and ospf protocols and for which, apparently, nobody 
has found yet any use.

Can we try to shutdown the unnecessary noise and confusion ?

Thanks.
s.


> On Jun 12, 2017, at 3:08 PM, Rob Shakir  wrote:
> 
> Bruno, SPRING,
> 
> I am aware of at least one implementation that makes heavy use of Binding 
> SIDs, so I do not think that this is something that we can remove from the 
> protocol specification.
> It seems to me that we have a number of cases that continue to exist that 
> make it useful to have them specified, particularly:
>   • Binding of a SID to a deeper label stack to prevent there being large 
> label stacks required on ingress. This is required due to limited push depth, 
> and limited readable label depths for hashing.
>   • Re-use of some other protocol's or network's forwarding path by a 
> device that is imposing an SR label stack.
> There is not an alternative construct that can be used for this purpose, so 
> we should not remove it.
> 
> In both of these cases there seems, to me, to be a use case for having the 
> information in the IGP in the case that an implementation computes TE paths 
> using cSPF, having binding SID information available to it (along with the 
> ERO) enables it to reduce the label stack depth by finding binding SIDs that 
> follow the same path as the computed ERO. Without the ERO (which might not be 
> an RSVP-TE ERO, but I believe that it how it was first envisaged) how can the 
> head-end of an TE path know what path the advertised Binding SID takes? It's 
> fine to punt this and say "the PCE in the sky will know" - however, I believe 
> SPRING's charter doesn't limit the technology to only centralised computation 
> of paths.
> 
> I don't believe current demand for this is a good reason to remove it from 
> the protocol specification - it is still somewhat early days for folks 
> deploying TE based on SR - where I think the Binding SID concept is most 
> important.
> 
> r.
> 
> On Mon, 12 Jun 2017 at 05:50  wrote:
> Hello SPRING WG,
> 
> I'd like to encourage discussion on this thread.
> 
> The related questions seem to be:
> - Binding SIDs:
> -  Is there any implementation?
> - Is it useful?
> - Does it need to be specified?
> 
> - Binding SIDs advertised in IGP:
> -  Is there any implementation?
>  - Is it useful?
> - Does it need to be specified?
> 
> As of today, there seem to be multiple SPRING (related) document that make 
> reference (define/use) to the Binding SIDs. e.g.
> - architecture 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
> - MPLS instantiation 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
> - non-protected paths 
> https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
> - SR policies: 
> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7
> 
> 
> However, it also seems a priori possible to define Binding SIDs and not 
> advertised them in the IGP. (e.g. by keeping them local to the PCE)
> 
> On a side note, if the Binding SIDs are removed from the IGP, do they need to 
> be removed from the BGP-LS extensions? [+IDR chairs]
> 
> Thanks,
> Regards,
> --Bruno
> 
> > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Monday, June 12, 2017 10:18 AM
>  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
>  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions 
> (would also effect
>  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
>  >
>  > Hi,
>  >
>  > I would like to get some feedback on the usage of the SID/Label Binding 
> TLV.
>  >
>  > Is there any implementation that uses SID/Label Binding TLV for
>  > advertising the SID/Label binding to a FEC as specified in section 6 of
>  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
>  > draft-ietf-isis-segment-routing-extensions-12?
>  >
>  > If not, do we see this as something we want to preserve in the IGP SR
>  > drafts?
>  >
>  > ISIS uses The SID/Label Binding TLV to advertise
>  > prefixes to SID/Label mappings, which is known to be supported by
>  > several implementations and that piece needs to be preserved.
>  >
>  > thanks,
>  > Peter
>  >
>  > On 09/06/17 19:04 , Peter Psenak wrote:
>  > > Acee,
>  > >
>  > > my question is whether we need the whole section 6 and the SID/Label
>  > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
>  > > SRMS advertisement like in ISIS.
>  > >
>  > > thanks,
>  > > Peter
>  > >
>  > >
>  > >
>  

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[bruno.decraene]

Hi Acee, authors

2 clarification questions inline [Bruno]

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, June 09, 2017 4:46 PM
To: OSPF WG List; spring@ietf.org; isis...@ietf.org
Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Corrected IS-IS WG alias – Please reply to this one.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, June 9, 2017 at 10:42 AM
To: OSPF WG List >, 
"spring@ietf.org" 
>, 
"i...@ietf.org" >
Cc: 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
 
>
Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also effect 
OSPFv3 and IS-IS)

Hi OSPF, ISIS, and SPRING WGs,

As part of the Alia’s AD review, she uncovered the fact that the ERO extensions 
in 6.1 and 6.2 are specified as far as encoding but are not specified as far as 
usage in any IGP or SPRING document. As document shepherd,  my proposal is that 
they simply be removed since they were incorporated as part of a draft merge 
and it appears that no one has implemented them (other than parsing).
[Bruno] Is the option to move those Binding SID IGP extensions in a different 
(WG) document opened/considered? Any opinion on this?

We could also deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV 
registry to delay usage of these code points for some time (or indefinitely ;^).
[Bruno] Are there reasons to make actions to delay/against such usage?

Thanks
Regards,
--Bruno

Thanks,
Acee

_

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

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

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

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Rob Shakir]

Bruno, SPRING,

I am aware of at least one implementation that makes heavy use of Binding
SIDs, so I do not think that this is something that we can remove from the
protocol specification. It seems to me that we have a number of cases that
continue to exist that make it useful to have them specified, particularly:

   - Binding of a SID to a deeper label stack to prevent there being large
   label stacks required on ingress. This is required due to limited push
   depth, and limited readable label depths for hashing.
   - Re-use of some other protocol's or network's forwarding path by a
   device that is imposing an SR label stack.

There is not an alternative construct that can be used for this purpose, so
we should not remove it.

In both of these cases there seems, to me, to be a use case for having the
information in the IGP in the case that an implementation computes TE paths
using cSPF, having binding SID information available to it (along with the
ERO) enables it to reduce the label stack depth by finding binding SIDs
that follow the same path as the computed ERO. Without the ERO (which might
not be an RSVP-TE ERO, but I believe that it how it was first envisaged)
how can the head-end of an TE path know what path the advertised Binding
SID takes? It's fine to punt this and say "the PCE in the sky will know" -
however, I believe SPRING's charter doesn't limit the technology to only
centralised computation of paths.

I don't believe current demand for this is a good reason to remove it from
the protocol specification - it is still somewhat early days for folks
deploying TE based on SR - where I think the Binding SID concept is most
important.

r.

On Mon, 12 Jun 2017 at 05:50  wrote:

> Hello SPRING WG,
>
> I'd like to encourage discussion on this thread.
>
> The related questions seem to be:
> - Binding SIDs:
> -  Is there any implementation?
> - Is it useful?
> - Does it need to be specified?
>
> - Binding SIDs advertised in IGP:
> -  Is there any implementation?
>  - Is it useful?
> - Does it need to be specified?
>
> As of today, there seem to be multiple SPRING (related) document that make
> reference (define/use) to the Binding SIDs. e.g.
> - architecture
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
> - MPLS instantiation
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
> - non-protected paths
> https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
> - SR policies:
> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7
>
>
> However, it also seems a priori possible to define Binding SIDs and not
> advertised them in the IGP. (e.g. by keeping them local to the PCE)
>
> On a side note, if the Binding SIDs are removed from the IGP, do they need
> to be removed from the BGP-LS extensions? [+IDR chairs]
>
> Thanks,
> Regards,
> --Bruno
>
> > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Monday, June 12, 2017 10:18 AM
>  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
>  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions
> (would also effect
>  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
>  >
>  > Hi,
>  >
>  > I would like to get some feedback on the usage of the SID/Label Binding
> TLV.
>  >
>  > Is there any implementation that uses SID/Label Binding TLV for
>  > advertising the SID/Label binding to a FEC as specified in section 6 of
>  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
>  > draft-ietf-isis-segment-routing-extensions-12?
>  >
>  > If not, do we see this as something we want to preserve in the IGP SR
>  > drafts?
>  >
>  > ISIS uses The SID/Label Binding TLV to advertise
>  > prefixes to SID/Label mappings, which is known to be supported by
>  > several implementations and that piece needs to be preserved.
>  >
>  > thanks,
>  > Peter
>  >
>  > On 09/06/17 19:04 , Peter Psenak wrote:
>  > > Acee,
>  > >
>  > > my question is whether we need the whole section 6 and the SID/Label
>  > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
>  > > SRMS advertisement like in ISIS.
>  > >
>  > > thanks,
>  > > Peter
>  > >
>  > >
>  > >
>  > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
>  > >> Corrected IS-IS WG alias – Please reply to this one.
>  > >> Thanks,
>  > >> Acee
>  > >>
>  > >> From: Acee Lindem >
>  > >> Date: Friday, June 9, 2017 at 10:42 AM
>  > >> To: OSPF WG List >,
>  > >> "spring@ietf.org "   > >> >, "i...@ietf.org "
>  > >> >
>  > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > >> 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Jeff Tantsura]

Hi,

I have got pretty much same view as Acee.
There are many application (future, to my knowledge no products) for which the 
concept of Binding SID (anchor node) is central, I’m aware of ISIS 
implementation, didn’t see OSPF.
 
Currently, I don’t see any use to ERO extensions, perhaps could be removed from 
base specs and added later, if/when clear use case shows up.
 
Cheers,
Jeff
 
On 6/12/17, 05:57, "Acee Lindem (acee)"  wrote:

Hi Bruno, 

Here is my view.  

On 6/12/17, 8:50 AM, "spring on behalf of bruno.decra...@orange.com"
 wrote:

>Hello SPRING WG,
>
>I'd like to encourage discussion on this thread.
>
>The related questions seem to be:
>- Binding SIDs:
>   -  Is there any implementation?
>   - Is it useful?
>   - Does it need to be specified?

Binding SIDs as an architectural concept are very useful and will be
leveraged by numerous use cases. For example, one implemented use case is
BGP SR-TE. 
>
>- Binding SIDs advertised in IGP:
>   -  Is there any implementation?
>- Is it useful?
>   - Does it need to be specified?

At least for OSPF(v3), we currently don’t see any usage of binding SIDs. I
believe there is a use case for IS-IS but I’ll defer to the authors of the
IS-IS SR draft and implementation to elaborate.

As for the Bind SID ERO extensions, to the best of my knowledge, they are
not implemented or used by either OSPF or IS-IS.

>
>As of today, there seem to be multiple SPRING (related) document that
>make reference (define/use) to the Binding SIDs. e.g.
>- architecture 
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3
>.5.2
>- MPLS instantiation
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#sect
>ion-2
>- non-protected paths
>https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#
>section-3.3
>- SR policies: 
>https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-0
>0#section-7
>
>
>However, it also seems a priori possible to define Binding SIDs and not
>advertised them in the IGP. (e.g. by keeping them local to the PCE)
>
>On a side note, if the Binding SIDs are removed from the IGP, do they
>need to be removed from the BGP-LS extensions? [+IDR chairs]

At least the ERO extensions should be removed.

Thanks,
Acee 
>
>Thanks,
>Regards,
>--Bruno
>
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Monday, June 12, 2017 10:18 AM
> > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
> > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions
>(would also effect
> > OSPFv3 and IS-IS) - REPLY TO THIS ONE
> > 
> > Hi,
> > 
> > I would like to get some feedback on the usage of the SID/Label
>Binding TLV.
> > 
> > Is there any implementation that uses SID/Label Binding TLV for
> > advertising the SID/Label binding to a FEC as specified in section 6 of
> > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
> > draft-ietf-isis-segment-routing-extensions-12?
> > 
> > If not, do we see this as something we want to preserve in the IGP SR
> > drafts?
> > 
> > ISIS uses The SID/Label Binding TLV to advertise
> > prefixes to SID/Label mappings, which is known to be supported by
> > several implementations and that piece needs to be preserved.
> > 
> > thanks,
> > Peter
> > 
> > On 09/06/17 19:04 , Peter Psenak wrote:
> > > Acee,
> > >
> > > my question is whether we need the whole section 6 and the SID/Label
> > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used
>for
> > > SRMS advertisement like in ISIS.
> > >
> > > thanks,
> > > Peter
> > >
> > >
> > >
> > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
> > >> Corrected IS-IS WG alias – Please reply to this one.
> > >> Thanks,
> > >> Acee
> > >>
> > >> From: Acee Lindem >
> > >> Date: Friday, June 9, 2017 at 10:42 AM
> > >> To: OSPF WG List >,
> > >> "spring@ietf.org "  > >> >, "i...@ietf.org "
> > >> >
> > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > >> "
> > >>  > >> >
> > 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Acee Lindem (acee)]

Hi Bruno, 

Here is my view.  

On 6/12/17, 8:50 AM, "spring on behalf of bruno.decra...@orange.com"
 wrote:

>Hello SPRING WG,
>
>I'd like to encourage discussion on this thread.
>
>The related questions seem to be:
>- Binding SIDs:
>   -  Is there any implementation?
>   - Is it useful?
>   - Does it need to be specified?

Binding SIDs as an architectural concept are very useful and will be
leveraged by numerous use cases. For example, one implemented use case is
BGP SR-TE. 
>
>- Binding SIDs advertised in IGP:
>   -  Is there any implementation?
>- Is it useful?
>   - Does it need to be specified?

At least for OSPF(v3), we currently don’t see any usage of binding SIDs. I
believe there is a use case for IS-IS but I’ll defer to the authors of the
IS-IS SR draft and implementation to elaborate.

As for the Bind SID ERO extensions, to the best of my knowledge, they are
not implemented or used by either OSPF or IS-IS.

>
>As of today, there seem to be multiple SPRING (related) document that
>make reference (define/use) to the Binding SIDs. e.g.
>- architecture 
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3
>.5.2
>- MPLS instantiation
>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#sect
>ion-2
>- non-protected paths
>https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#
>section-3.3
>- SR policies: 
>https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-0
>0#section-7
>
>
>However, it also seems a priori possible to define Binding SIDs and not
>advertised them in the IGP. (e.g. by keeping them local to the PCE)
>
>On a side note, if the Binding SIDs are removed from the IGP, do they
>need to be removed from the BGP-LS extensions? [+IDR chairs]

At least the ERO extensions should be removed.

Thanks,
Acee 
>
>Thanks,
>Regards,
>--Bruno
>
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Monday, June 12, 2017 10:18 AM
> > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
> > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions
>(would also effect
> > OSPFv3 and IS-IS) - REPLY TO THIS ONE
> > 
> > Hi,
> > 
> > I would like to get some feedback on the usage of the SID/Label
>Binding TLV.
> > 
> > Is there any implementation that uses SID/Label Binding TLV for
> > advertising the SID/Label binding to a FEC as specified in section 6 of
> > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
> > draft-ietf-isis-segment-routing-extensions-12?
> > 
> > If not, do we see this as something we want to preserve in the IGP SR
> > drafts?
> > 
> > ISIS uses The SID/Label Binding TLV to advertise
> > prefixes to SID/Label mappings, which is known to be supported by
> > several implementations and that piece needs to be preserved.
> > 
> > thanks,
> > Peter
> > 
> > On 09/06/17 19:04 , Peter Psenak wrote:
> > > Acee,
> > >
> > > my question is whether we need the whole section 6 and the SID/Label
> > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used
>for
> > > SRMS advertisement like in ISIS.
> > >
> > > thanks,
> > > Peter
> > >
> > >
> > >
> > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
> > >> Corrected IS-IS WG alias – Please reply to this one.
> > >> Thanks,
> > >> Acee
> > >>
> > >> From: Acee Lindem >
> > >> Date: Friday, June 9, 2017 at 10:42 AM
> > >> To: OSPF WG List >,
> > >> "spring@ietf.org "  > >> >, "i...@ietf.org "
> > >> >
> > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
> > >> "
> > >>  > >> >
> > >> Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would
>also
> > >> effect OSPFv3 and IS-IS)
> > >>
> > >> Hi OSPF, ISIS, and SPRING WGs,
> > >>
> > >> As part of the Alia’s AD review, she uncovered the fact that
>the ERO
> > >> extensions in 6.1 and 6.2 are specified as far as encoding but
>are
> > >> not specified as far as usage in any IGP or SPRING document. As
> > >> document shepherd,  my proposal is that they simply be removed
>since
> > >> they were incorporated as part of a draft merge and it appears
>that
> > >> no one has implemented them (other than parsing). We could also
> > >> deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV
> > >> registry to delay usage of these code points for some time (or
> > >> indefinitely ;^).
> > >>
> > >> Thanks,
> > >> Acee
> > >>
> > >
> > > .
> > >
> > 
> > 

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[bruno.decraene]

Hello SPRING WG,

I'd like to encourage discussion on this thread.

The related questions seem to be:
- Binding SIDs:
-  Is there any implementation?
- Is it useful?
- Does it need to be specified?

- Binding SIDs advertised in IGP:
-  Is there any implementation?
 - Is it useful?
- Does it need to be specified?

As of today, there seem to be multiple SPRING (related) document that make 
reference (define/use) to the Binding SIDs. e.g.
- architecture 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
- MPLS instantiation 
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
- non-protected paths 
https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
- SR policies: 
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7


However, it also seems a priori possible to define Binding SIDs and not 
advertised them in the IGP. (e.g. by keeping them local to the PCE)

On a side note, if the Binding SIDs are removed from the IGP, do they need to 
be removed from the BGP-LS extensions? [+IDR chairs]

Thanks,
Regards,
--Bruno

> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Monday, June 12, 2017 10:18 AM
 > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
 > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
 > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would 
 > also effect
 > OSPFv3 and IS-IS) - REPLY TO THIS ONE
 > 
 > Hi,
 > 
 > I would like to get some feedback on the usage of the SID/Label Binding TLV.
 > 
 > Is there any implementation that uses SID/Label Binding TLV for
 > advertising the SID/Label binding to a FEC as specified in section 6 of
 > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
 > draft-ietf-isis-segment-routing-extensions-12?
 > 
 > If not, do we see this as something we want to preserve in the IGP SR
 > drafts?
 > 
 > ISIS uses The SID/Label Binding TLV to advertise
 > prefixes to SID/Label mappings, which is known to be supported by
 > several implementations and that piece needs to be preserved.
 > 
 > thanks,
 > Peter
 > 
 > On 09/06/17 19:04 , Peter Psenak wrote:
 > > Acee,
 > >
 > > my question is whether we need the whole section 6 and the SID/Label
 > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
 > > SRMS advertisement like in ISIS.
 > >
 > > thanks,
 > > Peter
 > >
 > >
 > >
 > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
 > >> Corrected IS-IS WG alias – Please reply to this one.
 > >> Thanks,
 > >> Acee
 > >>
 > >> From: Acee Lindem >
 > >> Date: Friday, June 9, 2017 at 10:42 AM
 > >> To: OSPF WG List >,
 > >> "spring@ietf.org "  >> >, "i...@ietf.org "
 > >> >
 > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
 > >> "
 > >>  >> >
 > >> Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also
 > >> effect OSPFv3 and IS-IS)
 > >>
 > >> Hi OSPF, ISIS, and SPRING WGs,
 > >>
 > >> As part of the Alia’s AD review, she uncovered the fact that the ERO
 > >> extensions in 6.1 and 6.2 are specified as far as encoding but are
 > >> not specified as far as usage in any IGP or SPRING document. As
 > >> document shepherd,  my proposal is that they simply be removed since
 > >> they were incorporated as part of a draft merge and it appears that
 > >> no one has implemented them (other than parsing). We could also
 > >> deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV
 > >> registry to delay usage of these code points for some time (or
 > >> indefinitely ;^).
 > >>
 > >> Thanks,
 > >> Acee
 > >>
 > >
 > > .
 > >
 > 
 > ___
 > OSPF mailing list
 > o...@ietf.org
 > https://www.ietf.org/mailman/listinfo/ospf

_

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, 

Re: [spring] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Peter Psenak]

Hi,

I would like to get some feedback on the usage of the SID/Label Binding TLV.

Is there any implementation that uses SID/Label Binding TLV for 
advertising the SID/Label binding to a FEC as specified in section 6 of 
the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of 
draft-ietf-isis-segment-routing-extensions-12?


If not, do we see this as something we want to preserve in the IGP SR 
drafts?


ISIS uses The SID/Label Binding TLV to advertise
prefixes to SID/Label mappings, which is known to be supported by 
several implementations and that piece needs to be preserved.


thanks,
Peter

On 09/06/17 19:04 , Peter Psenak wrote:

Acee,

my question is whether we need the whole section 6 and the SID/Label
Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
SRMS advertisement like in ISIS.

thanks,
Peter



On 09/06/17 16:45 , Acee Lindem (acee) wrote:

Corrected IS-IS WG alias – Please reply to this one.
Thanks,
Acee

From: Acee Lindem >
Date: Friday, June 9, 2017 at 10:42 AM
To: OSPF WG List >,
"spring@ietf.org " >, "i...@ietf.org "
>
Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
"
>
Subject: OSPFv2 Segment Routing Extensions ERO Extensions (would also
effect OSPFv3 and IS-IS)

Hi OSPF, ISIS, and SPRING WGs,

As part of the Alia’s AD review, she uncovered the fact that the ERO
extensions in 6.1 and 6.2 are specified as far as encoding but are
not specified as far as usage in any IGP or SPRING document. As
document shepherd,  my proposal is that they simply be removed since
they were incorporated as part of a draft merge and it appears that
no one has implemented them (other than parsing). We could also
deprecate types (4-8) in the OSPFv2 Extended Prefix LSA Sub-TLV
registry to delay usage of these code points for some time (or
indefinitely ;^).

Thanks,
Acee



.



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