[Lsr] Questions about draft-ietf-lsr-flex-algo-06

[peng.shaofu]

Hi Peter






Please see the difference rules of TE metric in Flex-algo draft and RFC5305.


For  the link without TE metric attribute, in Flex-algo draft it will be 
excluded from FA plane that configured TE metric type, but in RFC5305 the IGP 
metric of the link can be as replacement.


Please see if they can be consistent ?





Flex-algo draft:

section 12.  Calculation of Flexible Algorithm Paths

Rule-5:

 5.  If the Flex-Algorithm definition uses other than IGP metric

  (Section 5), and such metric is not advertised for the particular

  link in a topology for which the computation is done, such link

  MUST be pruned from the computation.  A metric of value 0 MUST NOT

  be assumed in such case.







RFC5305:

section 3.7.  Sub-TLV 18: Traffic Engineering Default Metric

This sub-TLV is optional.  This sub-TLV SHOULD appear once at most in

   each extended IS reachability TLV.  If a link is advertised without

   this sub-TLV, traffic engineering SPF calculations MUST use the

   normal default metric of this link, which is advertised in the fixed

   part of the extended IS reachability TLV.___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] AD Review of draft-ietf-ospf-mpls-elc-12

[Alvaro Retana]

Dear authors:

This is my review of draft-ietf-ospf-mpls-elc-12.  I reviewed this
document alongside draft-ietf-isis-mpls-elc-10, so many comments are
the same/similar.  Thank you for the work in both of them!

I will progress both documents together, so I will wait for both of
them to address my comments before starting their IETF LC.

Thanks!!

Alvaro.


[Line numbers from idnits.]

...
14    Signaling Entropy Label Capability and Entropy Readable Label-stack
15                              Depth Using OSPF

[minor] s/Label-stack/Label

16                        draft-ietf-ospf-mpls-elc-12

18  Abstract

20     Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
21     balance traffic flows using Entropy Labels (EL).  An ingress Label
22     Switching Router (LSR) cannot insert ELs for packets going into a
23     given tunnel unless an egress LSR has indicated via signaling that it
24     has the capability to process ELs, referred to as Entropy Label
25     Capability (ELC), on that tunnel.  In addition, it would be useful
26     for ingress LSRs to know each LSR's capability of reading the maximum
27     label stack depth and performing EL-based load-balancing, referred to
28     as Entropy Readable Label Depth (ERLD).  This document defines a
29     mechanism to signal these two capabilities using OSPF and OSPFv3.
30     These mechanism is particularly useful in the environment where
31     Segment Routing (SR) is used, where label advertisements are done via
32     protocols like OSPF and OSPFv3.

[nit] s/given tunnel/given Label Switched Path (LSP)

[nit] s/as Entropy Label Capability/as the Entropy Label Capability

[nit] s/capability of reading/capability for reading

[minor] s/OSPF and OSPFv3/OSPFv2 and OSPFv3/g

[minor] Add some text in the Introduction pointing at the generic use
of "OSPF" to mean both OSPFv2 and OSPFv3.

[minor] "protocols like OSPF..."  That last sentence sounds as if
there were other options; for example advertise labels with IS-IS and
then use the extensions here.  It's just a minor point, but I think
that maybe that last sentence is not needed.



...
83  1.  Introduction
...
96     In addition, in the cases where stacked LSPs are used for whatever
97     reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it
98     would be useful for ingress LSRs to know each intermediate LSR's
99     capability of reading the maximum label stack depth and performing
100    EL-based load-balancing.  This capability, referred to as Entropy
101    Readable Label Depth (ERLD) as defined in
102    [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to
103    determine the position of the EL label in the stack, and whether it's
104    necessary to insert multiple ELs at different positions in the label
105    stack.

[minor] s/stacked LSPs/LSPs
I'm assuming there's no special significance of "stacked" in this
case, as this is the only place in the document that it is used.

[nit] s/in the cases where LSPs are used for whatever reasons/in cases
where LSPs are used


107 2.  Terminology

109    This document makes use of the terms defined in [RFC6790], [RFC7770]
110    and [I-D.ietf-mpls-spring-entropy-label].

[minor] I'm not sure why rfc7770 is referenced here; what terminology
is needed from it?


112    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
113    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
114    "OPTIONAL" in this document are to be interpreted as described in
115    [BCP14] [RFC2119] [RFC8174] when, and only when, they appear in all
116    capitals, as shown here.

[major] s/[BCP14]/BCP 14


118 3.  Advertising ELC Using OSPF

120    Even though ELC is a property of the node, in some cases it is
121    advantageous to associate and advertise the ELC with the prefix.  In
122    multi-area networks, routers may not know the identity of the prefix
123    originator in a remote area, or may not know the capabilities of such
124    originator.  Similarly, in a multi domain network, the identity of
125    the prefix originator and its capabilities may not be known to the
126    ingress LSR.

[nit] s/with the prefix/with a prefix

[minor] Is there a difference that are you trying to highlight between
multi-area and multi-domain?  The last two sentences seem redundant to
me; using "domain" should be enough.


128    If a router has multiple line cards, the router MUST NOT announce ELC
129    unless all of its line-cards are capable of processing ELs.

131    If the router supports ELs on all of its line cards, it SHOULD
132    advertise the ELC with every local host prefix it advertises in OSPF.

[major] From a general router architecture point of view, I understand
what you mean by line-card.  But, strictly 

[Lsr] AD Review of draft-ietf-isis-mpls-elc-10

[Alvaro Retana]

Dear authors:

This is my review of draft-ietf-isis-mpls-elc-10.  I reviewed this
document alongside draft-ietf-ospf-mpls-elc-12, so many comments are
the same/similar.  Thank you for the work in both of them!

Besides the in-line comments, I want to point out here that this
specification is incomplete.  It needs to have (1) a formal
description of the new MSD-Type (similar to §5/rfc8491), and (2) a
discussion of the interaction with the BMI-MSD.

I will progress both documents together, so I will wait for both of
them to address my comments before starting their IETF LC.

Thanks!!

Alvaro.


[Line numbers from idnits.]

...
18  Abstract

20     Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
21     balance traffic flows using Entropy Labels (EL).  An ingress Label
22     Switching Router (LSR) cannot insert ELs for packets going into a
23     given Label Switched Path (LSP) unless an egress LSR has indicated
24     via signaling that it has the capability to process ELs, referred to
25     as Entropy Label Capability (ELC), on that tunnel.  In addition, it
26     would be useful for ingress LSRs to know each LSR's capability for
27     reading the maximum label stack depth and performing EL-based load-
28     balancing, referred to as Entropy Readable Label Depth (ERLD).  This
29     document defines a mechanism to signal these two capabilities using
30     IS-IS.  These mechanisms are particularly useful, where label
31     advertisements are done via protocols like IS-IS.

[nit] s/as Entropy Label Capability/as the Entropy Label Capability

[minor] "protocols like IS-IS"  That last sentence sounds as if there
were other options; for example advertise labels with OSPF and then
use the extensions here.  It's just a minor point, but I think that
maybe that last sentence is not needed.


...
81  1.  Introduction

83     [RFC6790] describes a method to load-balance Multiprotocol Label
84     Switching (MPLS) traffic flows using Entropy Labels (EL).  "The Use
85     of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the
86     concept of Entropy Label Capability (ELC) and defines the signalings
87     of this capability via MPLS signaling protocols.  Recently,
88     mechanisms have been defined to signal labels via link-state Interior
89     Gateway Protocols (IGP) such as IS-IS
90     [I-D.ietf-isis-segment-routing-extensions].  In such scenarios, the
91     defined signaling mechanisms are inadequate.  This draft defines a
92     mechanism to signal the ELC using IS-IS.  This mechanism is useful
93     when the label advertisement is also done via IS-IS.

[nit] s/"The Use of Entropy Labels in MPLS Forwarding" [RFC6790]/It also

[nit] s/signalings/signaling

[nit] "In such scenarios, the defined signaling mechanisms are
inadequate." Take this sentence out: the rest of the paragraph is
enough.


95     In addition, in the cases where LSPs are used for whatever reasons
96     (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be
97     useful for ingress LSRs to know each intermediate LSR's capability of
98     reading the maximum label stack depth and performing EL-based load-
99     balancing.  This capability, referred to as Entropy Readable Label
100    Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may
101    be used by ingress LSRs to determine the position of the EL label in
102    the stack, and whether it's necessary to insert multiple ELs at
103    different positions in the label stack.

[nit] s/in the cases where LSPs are used for whatever reasons/in cases
where LSPs are used


105 2.  Terminology

107    This memo makes use of the terms defined in [RFC6790], [RFC4971] and
108    [I-D.ietf-mpls-spring-entropy-label].

[minor] I'm not sure why rfc4971 is referenced here; what terminology
is needed from it?


...
116 3.  Advertising ELC Using IS-IS

118    Even though ELC is a property of the node, in some cases it is
119    advantageous to associate and advertise the ELC with a prefix.  In a
120    multi-area network, routers may not know the identity of the prefix
121    originator in a remote area, or may not know the capabilities of such
122    originator.  Similarly in a multi-domain network, the identity of the
123    prefix originator and its capabilities may not be known to the
124    ingress LSR.

[minor] Is there a difference that are you trying to highlight between
multi-area and multi-domain?  The last two sentences seem redundant to
me; using "domain" should be enough.


126    One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"
127    registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by
128    the IANA for the ELC.  If a router has multiple line cards, the
129    router MUST NOT announce the ELC for any 

[Lsr] 答复: IETF 107 LSR Presentation Slot Requests

[wangyali]

Dear chairs, secretary and all,

This is Yali. It’s my honor to give a remote presentation for two new drafts 
(draft-liu-lsr-isis-ifit-node-capability-00 and 
draft-wang-lsr-ospf-ifit-node-capability-00) and request duration around 15 min 
for these two draft.

Everyone is welcome to give comments for these two drafts. Thank you.

Best regards,
Yali Wang

发件人: Yingzhen Qu [mailto:yingzhen.i...@gmail.com]
发送时间: 2020年2月29日 3:57
收件人: lsr@ietf.org; lsr-cha...@ietf.org
主题: [Lsr] IETF 107 LSR Presentation Slot Requests

Hi all,

We're now accepting agenda request for the LSR Working Grouping meeting IETF 
107. Please send your requests to 
lsr-cha...@ietf.org indicating draft name, speaker, 
and desired duration (covering presentation and discussion).

If you plan to present remotely, please let us know so we can make the 
arrangements with the Meetecho team.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] lsr - Requested sessions have been scheduled for IETF 107

["IETF Secretariat"]

Dear Acee Lindem,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


lsr Session 1 (2:00 requested)
Monday, 23 March 2020, Afternoon Session I 1330-1530
Room Name: Regency F size: 150
-
lsr Session 2 (1:00 requested)
Monday, 23 March 2020, Afternoon Session III 1810-1910
Room Name: Regency F size: 150
-


iCalendar: https://datatracker.ietf.org/meeting/107/sessions/lsr.ics

Request Information:


-
Working Group Name: Link State Routing
Area Name: Routing Area
Session Requester: Acee Lindem

Number of Sessions: 2
Length of Session(s):  2 Hours, 1 Hour
Number of Attendees: 100
Conflicts to Avoid: 
 Chair Conflict: ipsecme idr rtgwg lsvr
 Technology Overlap: rift spring
 Key Participant Conflict: bfd bess


People who must be present:
  Acee Lindem
  Christian Hopps
  Alvaro Retana

Resources Requested:

Special Requests:
  
-


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

[Lsr] IETF 107 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi all,

We're now accepting agenda request for the LSR Working Grouping meeting
IETF 107. Please send your requests to lsr-cha...@ietf.org indicating draft
name, speaker, and desired duration (covering presentation and discussion).

If you plan to present remotely, please let us know so we can make the
arrangements with the Meetecho team.

Thanks,
Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; SPRING WG List; draft-ietf-spring-srv6-network-programming; 
Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, 
by the receiver, of the following piece of information:

  LB Length: SRv6 SID Locator Block length
  LN Length: SRv6 SID Locator Node length
  Fun. Length: SRv6 SID Function length
  Arg. Length: SRv6 SID Arguments length


So perhaps I don’t get Chris’s point and would wait for him to clarify.
[Bruno] I’ll leave this to Chris.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



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 

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

So perhaps I don’t get Chris’s point and would wait for him to clarify.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[bruno.decraene]

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_

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.

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