Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

From: <[email-masked]>
Date: Thu, 2 Aug 2018 20:24:19 +0000

Hi authors,

Please find below some minor comments:

1) Abstract:
" In addition, this document introduces the Non-IGP Functional
   Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
   functional capabilities.  ELC is one of such non-IGP functional
   capabilities."

It's a matter of opinion but reducing the number of occurrences of " non-IGP functional capabilities" may improve the S/N ration.

2) 
   The format of the Router Non-IGP Functional Capabilities Sub-TLV is  as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type=TBD1  |    Length=4   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The sub-TLV is not hard coded/defined with a length of 4, hence this value should not be part of the definition.

3)
"Length: Indicates the length of the value portion in octets and  will be a multiple of 4 octets"

Possibly :s/will/MUST
Please specify the error handling. (e.g. disregards the whole sub-TLV, disregards the last 1 to 3 octets, accept the whole sub-TLV...)

4)
"One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)  is to be assigned by the IANA for the ELC [RFC6790]."

Since this document defines the new sub-TLV, it can freely do any allocation itself.

5)
"The registration procedure is "Expert Review" as defined in   [RFC8126]."

You may want to read RFC 8126 https://tools.ietf.org/html/rfc8126#section-4.5
Which, In particular, states:
" The registry's
   definition needs to make clear to registrants what information is
   necessary.  

  [...]

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.  It is also a good idea to include, when possible, a sense
   of whether many registrations are expected over time, or if the
   registry is expected to be updated infrequently or in exceptional
   circumstances only. "

6)
"This capability, referred to as Entropy  Readable Label Depth (ERLD) as defined in  [I-D.ietf-mpls-spring-entropy-label] "

This probably calls for this document to be a normative reference.

"   A new MSD-type of the Node MSD b-TLV
   [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to
   advertise the ERLD of a given router."

May be adding the reference to the document defining the ERLD:
OLD: advertise the ERLD
NEW: advertise the ERLD [I-D.ietf-mpls-spring-entropy-label]

7)
"If a router has
   multiple line cards, the router MUST NOT announce the ELC [RFC6790]
   unless all of its linecards are capable of processing ELs."

May be you mean
OLD: all of its linecards
OLD: all of the linecards of the links advertised as IS-IS adjacencies.

Regards,
--Bruno

 > -----Original Message-----
 > From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
 > Sent: Tuesday, July 31, 2018 4:07 PM
 > To: [email-masked]
 > Cc: [email-masked]
 > Subject: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 > 
 > 
 > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 > This draft is a work item of the Link State Routing WG of the IETF.
 > 
 >         Title           : Signaling Entropy Label Capability and Entropy Readable Label Depth Using
 > IS-IS
 >         Authors         : Xiaohu Xu
 >                           Sriganesh Kini
 >                           Siva Sivabalan
 >                           Clarence Filsfils
 >                           Stephane Litkowski
 > 	Filename        : draft-ietf-isis-mpls-elc-05.txt
 > 	Pages           : 7
 > 	Date            : 2018-07-29
 > 
 > Abstract:
 >    Multiprotocol Label Switching (MPLS) has defined a mechanism to load
 >    balance traffic flows using Entropy Labels (EL).  An ingress Label
 >    Switching Router (LSR) cannot insert ELs for packets going into a
 >    given tunnel unless an egress LSR has indicated via signaling that it
 >    has the capability of processing ELs, referred to as Entropy Label
 >    Capability (ELC), on that tunnel.  In addition, it would be useful
 >    for ingress LSRs to know each LSR's capability of reading the maximum
 >    label stack depth and performing EL-based load-balancing, referred to
 >    as Entropy Readable Label Depth (ERLD), in the cases where stacked
 >    LSPs are used for whatever reasons.  This document defines mechanisms
 >    to signal these two capabilities using IS-IS.  These mechanisms are
 >    useful when the label advertisement is also done via IS-IS.  In
 >    addition, this document introduces the Non-IGP Functional
 >    Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
 >    functional capabilities.  ELC is one of such non-IGP functional
 >    capabilities.
 > 
 > 
 > The IETF datatracker status page for this draft is:
 > https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
 > 
 > There are also htmlized versions available at:
 > https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05
 > https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-05
 > 
 > A diff from the previous version is available at:
 > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-mpls-elc-05
 > 
 > 
 > Please note that it may take a couple of minutes from the time of submission
 > until the htmlized version and diff are available at tools.ietf.org.
 > 
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 > 
 > _______________________________________________
 > Lsr mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 2 Aug 2018 20:50:37 +0000

Hi authors,

"4.  Advertising ELC Using IS-IS

   One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)
   is to be assigned by the IANA for the ELC [RFC6790]."

RFC6790 defines ELC capability on a per FEC/LSP egress basis.
Please defines what you mean exactly with this per node capability. If this is expected to advertise ELC capability in spring networks, it's not crystal clear to me how it works in multi-area/domain network with IP prefix/SID redistribution.
Possibly the ELC flag would need to be advertised on a per prefix basis.

Thanks,
Regards,
--Bruno

 > From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
 > Sent: Thursday, August 02, 2018 10:24 PM
 > To: [email-masked]
 > Cc: [email-masked]
 > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 > 
 > Hi authors,
 > 
 > It's a matter of opinion but reducing the number of occurrences of " non-IGP functional
 > capabilities" may improve the S/N ration.
 > 
 > 2)
 > __________________________________________________________________________

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 03 Aug 2018 10:13:15 +0800

Hi Bruno,

Thanks for raising this important issue.

In fact, the Routable IP Address TLVs/sub-TLVs as described in (https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02) and (https://tools.ietf.org/html/draft-xu-isis-routable-ip-address-01) respectively were intended to address the problem that you had mentioned (i.e., it is required for OSPF routers in one area to find correlations between routable IP addresses and capabilities of OSPF routers in another area). 

The following text is quoted from 

"    There are several situations where it is required for OSPF routers in
   one area to find correlations between routable IP addresses and
   capabilities of OSPF routers in another area.  One example is the
   Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc]
   across the OSPF domain.  In this example, assume the ELC TLV
   originated by a router in one area is propagated to another area.
   Those routers in the latter area need to find routable IP addresses
   of the router originating that ELC TLV before inserting the Entropy
   Label (EL) for packets going to the Label Switch Path (LSP) tunnel
   towards one of the above routable IP addresses..."

Later, such correlation requirement in the ISIS domain was addressed by introducing the source IPv4/IPv6 router ID sub-TLVs into the Extended Reachability TLVs (see https://tools.ietf.org/html/rfc7794). I forget whether the same extension to OSPF as RFC7794 has been done. 

Best regards,
Xiaohu
------------------------------------------------------------------
From:bruno.decraene <[email-masked]>
Send Time:2018年8月3日(星期五) 04:50
To:[email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi authors,

Thanks,
Regards,
--Bruno

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 07:45:41 +0000

Hi  Xiaohu,

Thanks for the reply.
You seem to assume/require that (router) capability advertisement be propagated across IGP areas/domains. If so,
- this is a new requirement for existing multi-area networks that need to be indicated in the draft
- I find this debatable. This point should be explicitly discussed. I’d rather advertise the ELC capability on a per Segment basis. This would also be better aligned with RFC 6790 hence safer if EL extensions are defined. The (Segment Routing) Prefix-SID sub-TLV has 2 flags remaining. This may be a good candidate as this information seems SR specific. Alternatively, RFC7794 may be used.

Thanks
Best regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Friday, August 03, 2018 4:13 AM
To: Lsr; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Bruno,

   Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc<https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02#ref-I-D.xu-ospf-mpls-elc>]

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 3 Aug 2018 16:32:29 +0000

Bruno –

I appreciate why you suggest per-prefix signaling for ELC, but I would prefer that we not employ that model.

ELC is clearly a node capability – signaling it in per node scope is therefore most appropriate. And it aligns with the SR model where we do not need to depend on hop-by-hop signaling as in the LDP case.

As regards the interarea issues you raise:

Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF) support domain-wide flooding scope. This is not a new capability – though I do agree with you that the ELC drafts should explicitly mention the flooding scope requirement.

As regards identifying the source of a prefix advertisement domain-wide, IS-IS has a complete solution for this as defined in RFC 7794.
OSPF is lacking support for advertising the source Router-ID, but this can be easily remedied by defining an extension using Extended Prefix LSA (as has been mentioned by Peter in another thread). And this functionality is needed for other reasons e.g., to know when PHP should/should not be done. So it is probably past time when this should be defined.

So I think it is better if we use the per-node ELC scope proposed in the ELC drafts.

As an aside, I would prefer that we utilize the existing TE Node Capability Descriptor registry defined in RFC 5073 rather than invent a new codepoint/registry (the proposed Non-IGP Functional  Capabilities registry) – but that is a minor point.

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, August 03, 2018 12:46 AM
To: 徐小虎(义先) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Friday, August 03, 2018 4:13 AM
To: Lsr; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Bruno,

Best regards,
Xiaohu
------------------------------------------------------------------
From:bruno.decraene <[email-masked]<mailto:[email-masked]>>
Send Time:2018年8月3日(星期五) 04:50
To:[email-masked] <[email-masked]<mailto:[email-masked]>>
Cc:[email-masked] <[email-masked]<mailto:[email-masked]>>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi authors,

Thanks,
Regards,
--Bruno

 > From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
 > To: [email-masked]<mailto:[email-masked]>
 > Cc: [email-masked]<mailto:[email-masked]>
 >  > From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
 >  > To: [email-masked]<mailto:[email-masked]>
 >  > Cc: [email-masked]<mailto:[email-masked]>
 >  > [email-masked]<mailto:[email-masked]>
 > [email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 03 Aug 2018 18:50:35 +0200

Hi Les, Bruno,

I volunteer to write the draft for OSPF Source Router ID advertisement 
in OSPF Extended Prefix LSA.

thanks,
Peter

On 03/08/18 18:32 , Les Ginsberg (ginsberg) wrote:
> ELC is clearly a node capability – signaling it in per node scope is
> therefore most appropriate. And it aligns with the SR model where we do
> not need to depend on hop-by-hop signaling as in the LDP case.
>
> Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF)
> support domain-wide flooding scope. This is not a new capability –
> though I do agree with you that the ELC drafts should explicitly mention
> the flooding scope requirement.
>
> As regards identifying the source of a prefix advertisement domain-wide,
> IS-IS has a complete solution for this as defined in RFC 7794.
>
> OSPF is lacking support for advertising the source Router-ID, but this
> can be easily remedied by defining an extension using Extended Prefix
> LSA (as has been mentioned by Peter in another thread). And this
> functionality is needed for other reasons e.g., to know when PHP
> should/should not be done. So it is probably past time when this should
> be defined.
>
> As an aside, I would prefer that we utilize the existing TE Node
> Capability Descriptor registry defined in RFC 5073 rather than invent a
> new codepoint/registry (the proposed Non-IGP Functional  Capabilities
> registry) – but that is a minor point.
>
>     Les
>
> *From:*Lsr <[email-masked]> *On Behalf Of [email-masked]
> *Sent:* Friday, August 03, 2018 12:46 AM
> *To:* 徐小虎(义先) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
>
> Hi  Xiaohu,
>
> Thanks for the reply.
>
> You seem to assume/require that (router) capability advertisement be
> propagated across IGP areas/domains. If so,
>
> - I find this debatable. This point should be explicitly discussed. I’d
> rather advertise the ELC capability on a per Segment basis. This would
> also be better aligned with RFC 6790 hence safer if EL extensions are
> defined. The (Segment Routing) Prefix-SID sub-TLV has 2 flags remaining.
> This may be a good candidate as this information seems SR specific.
> Alternatively, RFC7794 may be used.
>
> Thanks
>
> Best regards,
>
> --Bruno
>
> *From:*Lsr [mailto:[email-masked]] *On Behalf Of *???(??)
> *Sent:* Friday, August 03, 2018 4:13 AM
> *To:* Lsr; [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
>
> Hi Bruno,
>
> In fact, the Routable IP Address TLVs/sub-TLVs as described in
> (https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02) and
> (https://tools.ietf.org/html/draft-xu-isis-routable-ip-address-01) respectively
> were intended to address the problem that you had mentioned (i.e., it is
> required for OSPF routers in one area to find correlations between
> routable IP addresses and capabilities of OSPF routers in another area).
>
>     Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc  <https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02#ref-I-D.xu-ospf-mpls-elc>]
>
> Later, such correlation requirement in the ISIS domain was addressed by
> introducing the source IPv4/IPv6 router ID sub-TLVs into the Extended
> Reachability TLVs (see https://tools.ietf.org/html/rfc7794). I
> forget whether the same extension to OSPF as RFC7794 has been done.
>
> Best regards,
>
> Xiaohu
>
>     To:[email-masked]
>     <[email-masked]
>     <mailto:[email-masked]>>
>
>     Cc:[email-masked] <[email-masked] <mailto:[email-masked]>>
>
>       > From: Lsr [mailto:[email-masked]] On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>       > Cc: [email-masked] <mailto:[email-masked]>
>       > You may want to read RFC 8126
>     https://tools.ietf.org/html/rfc8126#section-4.5
>       >  > From: Lsr [mailto:[email-masked]] On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>       >  > To: [email-masked] <mailto:[email-masked]>
>       >  > Cc: [email-masked] <mailto:[email-masked]>
>       >  > [email-masked] <mailto:[email-masked]>
>       > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 17:00:40 +0000

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, August 03, 2018 6:32 PM
To: DECRAENE Bruno IMT/OLN; 徐小虎(义先)
Cc: [email-masked]; [email-masked]
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Bruno –

I appreciate why you suggest per-prefix signaling for ELC, but I would prefer that we not employ that model.
[Bruno] Thanks for the feedback. That’s part of the discussion that I was calling for.

ELC is clearly a node capability

[Bruno] It’s a node capability of the egress of the LSP. Hence it could also be seen as a property of the LSP ;-) RFC 6790 says  “one may choose to associate ELs with MPLS tunnels (LSPs) or
   with MPLS applications […] We take the former approach”

– signaling it in per node scope is therefore most appropriate. And it aligns with the SR model where we do not need to depend on hop-by-hop signaling as in the LDP case.
[Bruno] I would argue that advertising ELC per prefix is not a hop-by-hop signaling as in the LDP case. That’s one single advertisement per area/level.

Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF) support domain-wide flooding scope. This is not a new capability
[Bruno] Agreed.

– though I do agree with you that the ELC drafts should explicitly mention the flooding scope requirement.
[Bruno] May be the scalability impact may need to be discussed. I would assume an impact on the size of the LSDB (but a priori no impact on the churn). This is also a new behavior which may surprise operational teams.

[Bruno] I also raised the case of redistribution of IP prefix/SID between IGP domains. Possibly one using OSPF and one using IS-IS. This case needs to be also covered.

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 3 Aug 2018 12:14:11 -0700

+1
Nothing really to add to Les’ comments 

Regards,
Jeff

> On Aug 3, 2018, at 09:32, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Bruno –
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 3 Aug 2018 21:27:00 +0000

Bruno –

Inline.

From: [email-masked] <[email-masked]>
Sent: Friday, August 03, 2018 10:01 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; 徐小虎(义先) <[email-masked]>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Les,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bruno –

[Les:] I probably expressed this poorly.
As LDP does hop-by-hop signaling the “natural” way to signal this in LDP is in the neighbor label exchanges.
However, SR signaling is scoped by the area/domain and therefore we have the ability to advertise capability in a way that matches how the support is actually enabled. There is no basis for a node to advertise ELC support for local Prefix A but not for Local Prefix B. So advertising this per prefix is redundant (though I agree is still possible).

– though I do agree with you that the ELC drafts should explicitly mention the flooding scope requirement.
[Bruno] May be the scalability impact may need to be discussed. I would assume an impact on the size of the LSDB (but a priori no impact on the churn). This is also a new behavior which may surprise operational teams.
[Les:] The significant issue as regards scale is the leaking of the prefixes – not the leaking of per-Node information. So I am not greatly concerned about leaking Node Capability info.

[Les:] If a prefix is leaked between protocols then you lose the identification of the source. Which means you have other considerations which are not met e.g., what is the value for ERLD (which also is clearly not a per prefix value). To know this you need to know the source and have the Node Capabilities.

    Les

Thanks,
Regards,
--Bruno

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, August 03, 2018 12:46 AM
To: 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 08:24:12 +0000

Les,

Please see inline [Bruno2]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, August 03, 2018 11:27 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; 徐小虎(义先)
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Bruno –

Inline.

Les,

Bruno –

[Les:] I probably expressed this poorly.
As LDP does hop-by-hop signaling the “natural” way to signal this in LDP is in the neighbor label exchanges.
However, SR signaling is scoped by the area/domain and therefore we have the ability to advertise capability in a way that matches how the support is actually enabled. There is no basis for a node to advertise ELC support for local Prefix A but not for Local Prefix B. So advertising this per prefix is redundant (though I agree is still possible).
[Bruno2] Let’s not mix the discussion between protocol signaling behavior (hop-by-hop vs 1 origination then flood per area/domain) and granularity of the ELC semantic (per prefix/LSP vs per node).
- I think we all agree that irrespectively of the information that we choose to advertise, link state IGP do one (single) origination per area/domain, and there is no such hop-by-hop signaling.
- Regarding the granularity of the ELC signaling, I think that this is open for discussion. One node may both advertise a prefix for which it is the egress (e.g. its loopback) and a prefix for which it is not the egress (e.g. a prefix redistributed from static route of another protocol (e.g. another IGP from a domain running LDP))
We would like to use EL for the former and must not use EL for the latter.

If we choose to advertise the ELC on a per node basis, there are a few sub-cases:
a) node is ELC capable but advertise prefixes for which it is not the egress
- EL MUST NOT be used for this prefix
- this may probably be handled by using the R-flag (if set, EL MUST NOT be used)

b) node is ELC capable but advertise prefixes for which it is not the egress, and for which the egress support ELC
- EL SHOULD be used for this prefix
- I’m not currently seen a way to handle this, except doing the ELC signaling on a per prefix basis

c) node is not ELC capable but advertise prefixes for which it is not the egress, but for which the egress support ELC
- EL SHOULD be used for this prefix
- I’m not currently seen a way to handle this, except doing the ELC signaling on a per prefix basis

[Les:] If a prefix is leaked between protocols then you lose the identification of the source. Which means you have other considerations which are not met e.g., what is the value for ERLD (which also is clearly not a per prefix value). To know this you need to know the source and have the Node Capabilities.
[Bruno2] Again, let’s not mix the discussion with ERLD which is different (e.g. indeed per node behavior, best effort while for ELC one MUST NOT use EL is the egress of the LSP/segment does not support EL)

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 08:25:58 +0000

Hi,

Hi Les, Bruno,

[SLI] I agree with Les that we are losing the ERLD information. But I think it is worth allowing the propagation of the ELC even if we are losing the ERLD info. We make this propagation optional. Moreover it will be still optional for the ingress node to use it.
I agree that we must not leak the node infos.

The other case to handle is the binding SID. The binding SID needs to reflect the ELC of the associated LSP.
The SRMS case is also interesting if we want to enable entropy when doing SR-LDP interworking.

Sent: Friday, August 03, 2018 23:27

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 6 Aug 2018 08:46:49 +0000

“
“

Does this not assume that a LSP is strictly defined hop-by-hop? If LSP is a loose LSP, then it is very well possible that
depending on the state of network, sometimes the LSP is ELC capable and another time it is not capable or the ERLD changes.

I’m not convinced or have clear understanding on the value of ELC/ERLD for a particular LSP without making some strict prescriptions on LSP.

To me, having ERLD (and maybe of less importance) ELC has value only for a controller to make more educated decisions upon packet flows.
Having such information per LSP seems complex and of lesser value as per node in the network.

G/

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, August 6, 2018 10:26
To: Les Ginsberg (ginsberg) <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>
Cc: [email-masked]; [email-masked]; 徐小虎(义先) <[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi,

Hi Les, Bruno,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 徐小虎(义先)

Bruno –

Inline.

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 03, 2018 10:01 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 09:57:34 +0000

Hi Gunter,

IMO, there are multiple cases to distinguish.

The basic case (Adj-SIDs & Prefix-SIDs, single area, single domain, single protocol):

-          ELC as a node property is a good thing. I personally do not see a use case to get some segments to be ELC and some others not to be ELCs.

Multiarea case:

-          When prefixes are leaked from one area to the other, we are losing the per node properties (like the ERLD). If we want to get benefit of EL, the ingress node in one area should get the ELC status of nodes in the other areas.

-          One solution would be to propagate the ELC as part of the prefix advertisement (when the prefix is leaked). We are still losing the ERLD which may impact the loadbalancing (EL/ELI placement not efficient).

-          Another solution could be for the ingress node to retrieve the ERLD from another source of information like BGP-LS but that’s not trivial as the ingress must know the best route to the tail from the ABR point of view.

Multiprotocol case:

-          It’s not really different than the multiarea case.

SRMS and SR-LDP stitching:

·         SR to LDP: the LDP tail-end may be ELC, if an SR ingress node wants to use an ELI/EL on top of the prefix SID associated to the LDP FEC, we need to propagate the ELC known from LDP (attached to the FEC) to the SR advertisement. The SR-LDP stitching node is not a tail-end node, it will do a label swap, not a pop then push. So an entropy label pushed by the SR ingress node will be carried to the tail-end LDP node. Am I wrong ?

·         LDP to SR: the stitching node knows if the tail-end SR node is ELC (through the IGP advertisement). It may propagate the ELC into LDP. All the prefixes of the tail-end SR node which are LDP FECs can get the ELC set if the SR tail-end node is ELC.
I do not see any strict prescription requirement for the LSP here.

Binding SID:

-          Binding SID associated to an SRTE LSP: if an ingress node wants to put an ELI/EL next to a binding SID, it needs to ensure that the tail-end of the binding SID is ELC. In addition, the expansion of the binding SID may introduce new ELI/ELs  as part of the new added label stack.

-          Binding SID associated to an RSVP-TE LSP: this case was removed from the SR extensions, but if it is revived in future, the ELC status of the RSVP-TE LSP may need to be propagated to the SR domain as part of the binding SID advertisement if we want the ingress to be able to push an ELI/ELI next to the BSID.

Brgds,

Stephane

From: Van De Velde, Gunter (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: Monday, August 06, 2018 10:47
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; 徐小虎(义先)
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Aug 2018 23:53:29 +0000

Stephane –

There are some issues you raise that I think are easily resolved/agreed upon – some others that may require more discussion.
Responses inline.

From: [email-masked] <[email-masked]>
Sent: Monday, August 06, 2018 2:58 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>
Cc: [email-masked]; [email-masked]; 徐小虎(义先) <[email-masked]>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Gunter,

[Les:] Good – I think there is general agreement on this point.

Multiarea case:

[Les:] There is no issue with multiarea.  Repeating some points made earlier in the thread:

Both IGPs have the ability to leak router capabilities/info between areas. Which means the node based attributes ELC and ERLD can be available domain-wide.
We also have the ability to leak source router-id with the leaked prefixes (OSPF has a gap here but we have a commitment to address that with a modest extension to the protocol – which needs to be done for multiple reasons.)
So all the information necessary is available in all areas.

Multiprotocol case:

[Les:] Multiprotocol is quite different than multiarea.
In the case of multiprotocol we do not have the ability to know/advertise the original source router-id nor the node capabilities in the destination protocol. It is not even guaranteed that reachability to the router-id of the source protocol is available in the area of the destination protocol.
This is where a controller based solution is most advantageous as it has the ability to learn all of that information from all of the protocols enabled in the domain.

[Les:] Here there is more room for differences of opinion.
One viewpoint is that SR-LDP interworking is a transition strategy. Any solution which attempts to exchange ELC/ELRD information between the SR<->LDP portions of the network will be “messy” and perhaps not worth the trouble as we hope that the transition will be “short-lived”.

Another viewpoint could be that if the transition period is long enough it may be useful to have such support.

But as any solution (even if we were to advertise ELC per prefix) would be non-trivial, I think there needs to be a strong case for taking this on.
Do you believe we have a strong case here?

Binding SID:

[Les:] I don’t appreciate the problem here.
I think you are talking about two possible EL use cases.

1)An ingress node which imposes the binding-SID may wish to utilize entropy on the path to the owner of the Binding-SID. As the node sid (or possibly an adj-sid advertised by the owner of the binding sid) will be needed in the label stack, the ingress node still knows – independent of the binding-sid, whether the owner is ELC.

2)When the packet arrives at the node which owns the binding SID, that node may wish to include EL in the label stack which it imposes to implement the policy defined by the binding SID. But as the ELC of the LSP tail end is known this should not be a problem. And I do not see why the ingress node that imposed the binding-sid needs to know whether the owner of the binding-sid will/will not impose EL.

   Les

Brgds,

Stephane

“

G/

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 6, 2018 10:26
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; DECRAENE Bruno IMT/OLN <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 08 Aug 2018 17:57:39 -0700

Stephane,

Leaving protocol semantics aside – do you see a real use cases for multi-area/multi-protocol scenarios? 

For all practical reasons (and to repeat Gunter’s comments) – this info is really of value for the controller, from distribution prospective, source->BGP-LS speaker, deployment wise, I believe most people strive to have a pair of BGP-LS speakers per area/level.

Area/level scoop would just good enough, don’t you think?

Thanks!

Cheers,

Jeff

From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Wednesday, August 8, 2018 at 16:54
To: "[email-masked]" <[email-masked]>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>, DECRAENE Bruno IMT/OLN <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "徐小虎 (义先)" <[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane –

Responses inline.

Hi Gunter,

The basic case (Adj-SIDs & Prefix-SIDs, single area, single domain, single protocol):
ELC as a node property is a good thing. I personally do not see a use case to get some segments to be ELC and some others not to be ELCs.

Multiarea case:
When prefixes are leaked from one area to the other, we are losing the per node properties (like the ERLD). If we want to get benefit of EL, the ingress node in one area should get the ELC status of nodes in the other areas.
One solution would be to propagate the ELC as part of the prefix advertisement (when the prefix is leaked). We are still losing the ERLD which may impact the loadbalancing (EL/ELI placement not efficient).
Another solution could be for the ingress node to retrieve the ERLD from another source of information like BGP-LS but that’s not trivial as the ingress must know the best route to the tail from the ABR point of view.

Multiprotocol case:
It’s not really different than the multiarea case.

SRMS and SR-LDP stitching:
SR to LDP: the LDP tail-end may be ELC, if an SR ingress node wants to use an ELI/EL on top of the prefix SID associated to the LDP FEC, we need to propagate the ELC known from LDP (attached to the FEC) to the SR advertisement. The SR-LDP stitching node is not a tail-end node, it will do a label swap, not a pop then push. So an entropy label pushed by the SR ingress node will be carried to the tail-end LDP node. Am I wrong ?
LDP to SR: the stitching node knows if the tail-end SR node is ELC (through the IGP advertisement). It may propagate the ELC into LDP. All the prefixes of the tail-end SR node which are LDP FECs can get the ELC set if the SR tail-end node is ELC.
I do not see any strict prescription requirement for the LSP here.

Binding SID:
Binding SID associated to an SRTE LSP: if an ingress node wants to put an ELI/EL next to a binding SID, it needs to ensure that the tail-end of the binding SID is ELC. In addition, the expansion of the binding SID may introduce new ELI/ELs  as part of the new added label stack.
Binding SID associated to an RSVP-TE LSP: this case was removed from the SR extensions, but if it is revived in future, the ELC status of the RSVP-TE LSP may need to be propagated to the SR domain as part of the binding SID advertisement if we want the ingress to be able to push an ELI/ELI next to the BSID.

   Les

Brgds,

Stephane

“

“

G/

Hi,

Hi Les, Bruno,

 

Bruno –

Inline.

Les,

Bruno –

 

[Bruno] Agreed.

    Les

Thanks,

Regards,

--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks

Best regards,

--Bruno

Hi Bruno,

Best regards,

Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

 

 

 
 
_______________________________________________ Lsr mailing list [email-masked] https://www.ietf.org/mailman/listinfo/lsr

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 09 Aug 2018 10:40:08 +0800

I agree with Les's points.

To clarify the usage of the ELC in the inter-area scenario, I would like to add the following text to draft-ietf-isis|ospf-mpls-elc:

"When the ELC advertisement originated by a router in one area is propagated to another area in the inter-area scenario, those routers in the latter area need to find the routable IP addresses of the router originating that ELC advertisement before inserting the Entropy Label (EL) for packets going to the Label Switch Path (LSP) tunnel towards one of the above routable IP addresses. How to find the correlation between the Router-ID and the routable IP address of a given router is outside the scope of this document. Note that how to find the correlation between the Router-ID and the routable IP address of a given router in an ISIS domain is described in [RFC7794]. "

Any comments and suggestions are welcome.

Best regards,
------------------------------------------------------------------
From:Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Send Time:2018年8月9日(星期四) 07:54
To:[email-masked] <[email-masked]>; "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>
Cc:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>; 徐小虎(义先) <[email-masked]>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane –

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

G/

Hi Les, Bruno,

Inline.

From:[email-masked] <[email-masked]> 

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

 Thanks,
 Regards,
 --Bruno

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 08:53:40 +0000

Hi Les,

Please see inline comments.

Brgds,

Stephane

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 01:53
To: LITKOWSKI Stephane OBS/OINIS; Van De Velde, Gunter (Nokia - BE/Antwerp); DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; 徐小虎(义先)
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane –

Hi Gunter,

Multiarea case:

[SLI2] Ok cool. If we go this way, don’t you think it would be useful to add a statement in the draft telling that such information (router cap+source-id) needs to be leaked ?

Multiprotocol case:

[SLI2] Based on what you previously said, I agree that it is different.
We have such deployment in our network, so we need a solution for the multiprotocol stuff.
For this use  case, I agree with Bruno that setting the ELC on a per prefix basis may be the easiest solution.
As a consequence, if per prefix ELC is required for the multiprotocol case, there is no more reason to maintain the per node ELC.

•         SR to LDP: the LDP tail-end may be ELC, if an SR ingress node wants to use an ELI/EL on top of the prefix SID associated to the LDP FEC, we need to propagate the ELC known from LDP (attached to the FEC) to the SR advertisement. The SR-LDP stitching node is not a tail-end node, it will do a label swap, not a pop then push. So an entropy label pushed by the SR ingress node will be carried to the tail-end LDP node. Am I wrong ?

•         LDP to SR: the stitching node knows if the tail-end SR node is ELC (through the IGP advertisement). It may propagate the ELC into LDP. All the prefixes of the tail-end SR node which are LDP FECs can get the ELC set if the SR tail-end node is ELC.
I do not see any strict prescription requirement for the LSP here.

[SLI2] No, I’m not telling that there is a strong case. If we explicitly do not want to support it, it would be worth mentioning it in the draft.
I see a real complexity in the advertisement if we want to make it working. Disaggregation of the SRMS range may be necessary. In the worst case, a per /32 range will be required with properties for each range. I personally do not want to go in this but again the draft should mention that we are aware of this.

Binding SID:

[SLI2] I think there is a slight misunderstanding here.
Let me try to do a simple figure:

A --- B ---- C ---- D ---- E ---- F --- G

A is the ingress node.
C is owner of a BSID. The BSID corresponds to the path CDEF.

A pushes a label stack {Adj_BC, BSID_C, Node_G}
A may insert an ELI/EL next to the BSID_C like : {Adj_BC, BSID_C, ELI, EL, Node_G}.
In order to do so, A must know if the tail-end of the LSP associated with BSID_C is ELC.
When the packet enters C with { BSID_C, ELI, EL, Node_G}, C expands the BSID with the following stack { Adj_DE, Adj_EF }. It swaps BSID_C to Adj_EF and pushes Adj_DE. The packet exists C with the following label stack {Adj_DE, Adj_EF, ELI, EL, Node_G}. Optionally, C may be able to add an additional ELI/EL when pushing adj_DE. But let’s forget this for this example.
When the packet enters F, F needs to be able to process the ELI/ELI. That’s the reason why A needs to be aware of node F ELC through the binding SID advertisement.

The problem comes because of the label swap on C. The other approach could be to tell that the LSP associated with the BSID label stops on the owner of the BSID and another one starts, each one being independent in term of ELC.
When the packet enters C with { BSID_C, ELI, EL, Node_G}, C expands the BSID with the following stack { Adj_DE, Adj_EF }. It pops BSID_C and the ELI/EL and pushes {Adj_DE, Adj_EF}.
In this solution, the ELC property of the BSID is the ELC property of C.

From an MPLS architecture point of view, doing a swap+push or pop+double push does not mean the same thing in term of LSP continuity and there is some implication for the ELC behind.

I do not see any document telling about the forwarding behavior expected for the binding SID.

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 08:54:28 +0000

Hi Jeff,

We have use cases for both inter-area and multiprotocol.

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 02:58
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane OBS/OINIS; Van De Velde, Gunter (Nokia - BE/Antwerp); DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; 徐小虎 (义先)
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane,

Thanks!

Cheers,
Jeff

Stephane –

Hi Gunter,

  *   ELC as a node property is a good thing. I personally do not see a use case to get some segments to be ELC and some others not to be ELCs.

Multiarea case:

  *   When prefixes are leaked from one area to the other, we are losing the per node properties (like the ERLD). If we want to get benefit of EL, the ingress node in one area should get the ELC status of nodes in the other areas.
  *   One solution would be to propagate the ELC as part of the prefix advertisement (when the prefix is leaked). We are still losing the ERLD which may impact the loadbalancing (EL/ELI placement not efficient).
  *   Another solution could be for the ingress node to retrieve the ERLD from another source of information like BGP-LS but that’s not trivial as the ingress must know the best route to the tail from the ABR point of view.

Multiprotocol case:
·         It’s not really different than the multiarea case.

  *   SR to LDP: the LDP tail-end may be ELC, if an SR ingress node wants to use an ELI/EL on top of the prefix SID associated to the LDP FEC, we need to propagate the ELC known from LDP (attached to the FEC) to the SR advertisement. The SR-LDP stitching node is not a tail-end node, it will do a label swap, not a pop then push. So an entropy label pushed by the SR ingress node will be carried to the tail-end LDP node. Am I wrong ?
  *   LDP to SR: the stitching node knows if the tail-end SR node is ELC (through the IGP advertisement). It may propagate the ELC into LDP. All the prefixes of the tail-end SR node which are LDP FECs can get the ELC set if the SR tail-end node is ELC.
I do not see any strict prescription requirement for the LSP here.

Binding SID:
·         Binding SID associated to an SRTE LSP: if an ingress node wants to put an ELI/EL next to a binding SID, it needs to ensure that the tail-end of the binding SID is ELC. In addition, the expansion of the binding SID may introduce new ELI/ELs  as part of the new added label stack.
·         Binding SID associated to an RSVP-TE LSP: this case was removed from the SR extensions, but if it is revived in future, the ELC status of the RSVP-TE LSP may need to be propagated to the SR domain as part of the binding SID advertisement if we want the ingress to be able to push an ELI/ELI next to the BSID.

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 09:30:54 +0000

Xiaohu,

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 4:40 AM

[Bruno] Please also clarify the usage of ELC in the inter-protocol/AS case. At minimum acknowledging that this solution does not work in this case.

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

From:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 09:30:55 +0000

Jeff,

For the RLD part, I agree that the node computing the SID list (ingress or PCE) reasonably needs the topology end to end, e.g. using BGP-LS.
For the entropy capability, we need this to work for shortest path/single SID LSP. i.e. the same as LDP ones, for which no controller is involved.

I have use case for both inter-area networks -which can be made to work with per node capability- and multi-protocol/AS scenario (inter AS VPN option C with no MPLS hierarchy).

I can remember a previous argument 2 weeks ago “IETF defines solutions that MUST work for all possible scenarios, not only for a specific one.”
So let’s not change the argument on a per thread basis.

Thanks,
Cheers,
--Bruno

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 2:58 AM
To: Les Ginsberg (ginsberg); LITKOWSKI Stephane OBS/OINIS; Van De Velde, Gunter (Nokia - BE/Antwerp); DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; ??? (??)
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane,

Thanks!

Cheers,
Jeff

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 09:30:58 +0000

Les,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 1:53 AM
To: LITKOWSKI Stephane OBS/OINIS; Van De Velde, Gunter (Nokia - BE/Antwerp); DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; ???(??)
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane –

Hi Gunter,

[Les:] Good – I think there is general agreement on this point.
[Bruno] ELC is a node property of the egress of the LSP. When a node advertise prefix/FEC for which it is not the egress, one need to know the ELC capability on a per FEC basis.

Multiarea case:

Multiprotocol case:

[Les:] Multiprotocol is quite different than multiarea.
In the case of multiprotocol we do not have the ability to know/advertise the original source router-id nor the node capabilities in the destination protocol. It is not even guaranteed that reachability to the router-id of the source protocol is available in the area of the destination protocol.
This is where a controller based solution is most advantageous as it has the ability to learn all of that information from all of the protocols enabled in the domain.
[Bruno] controller is a feature, not a requirement. There are existing deployments with inter-protocol/AS LSP not using a controller (because shortest path is good enough)

--Bruno

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 10 Aug 2018 03:51:58 +0000

Stephane –

Responses inline – look for LES2

From: [email-masked] <[email-masked]>
Sent: Thursday, August 09, 2018 1:54 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>
Cc: [email-masked]; [email-masked]; 徐小虎(义先) <[email-masked]>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Les,

Brgds,

Stephane

Stephane –

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 06, 2018 2:58 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; DECRAENE Bruno IMT/OLN <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Gunter,

Multiarea case:

[Les2:] Agreed. I think I already made that statement earlier in the thread.

Multiprotocol case:

[Les2:]  It is not that simple. It is still necessary to know ERLD – and there is no mechanism to leak that between protocols. There are also the issues with router-id I mentioned above.
I appreciate that multiprotocol may be a real world deployment case – but I think the best suggestion here is to use a controller. If that does not suffice then there is much more required than advertising ELC along with prefixes.

[Les2:] OK – I take this to mean we agree we do not have to solve this issue. As for covering this in a draft, I agree it would be good to discuss such issues – but I don’t think the ELC drafts are the best place. It would be better to put this into a generic policy framework draft as the issues are not confined to SR-LDP. I see some similarity to the multiprotocol case. Sharing attributes between different protocols – be they two IGPs or two label distribution mechanisms – is problematic.

Binding SID:

A is the ingress node.

[Les2:] A is trying to setup an LSP from A->G. As such, A should only be interested in ELC of G.
The fact that C may insert an “inner LSP” to F should be irrelevant to A. But I take your point that there are two possible behaviors on C and at the moment which behavior is expected is not specified.

1)(ELI, EL) following a BSID is associated with the BSID owner and should be popped by C when it imposes the LSP associated with the BSID

Or

2)(ELI,EL) following a BSID is associated with the endpoint of the LSP defined by the ingress node (A in this case) and should NOT be popped when the inner LSP associated with the BSID is pushed.

I prefer #2 – it means the introduction of BSID does not change existing EL behavior. But I am interested in what other folks think.

  Les

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 10 Aug 2018 14:18:26 +0800

Bruno,

OK. I will add the text as follows: "How to apply the ELC advertisement in the inter-AS and inter-protocol scenarios is outside the scope of this document".

Best regards,
Xiaohu

------------------------------------------------------------------
From:bruno.decraene <[email-masked]>
Send Time:2018年8月9日(星期四) 17:32
To:徐小虎(义先) <[email-masked]>; Lsr <[email-masked]>; LITKOWSKI Stephane OBS/OINIS <[email-masked]>; "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Cc:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Xiaohu,

From:徐小虎(义先) [mailto:[email-masked]] 
Sent: Thursday, August 09, 2018 4:40 AM

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

 Thanks,
 Regards,
 --Bruno

---

From: <[email-masked]>
Date: Fri, 10 Aug 2018 08:03:30 +0000

Hi Les,

More inline (I’m stripping the unnecessary text). See [SLI3]

Brgds,

Sent: Friday, August 10, 2018 05:52

Stephane –

Multiprotocol case:

[SLI3] The ERLD allows the ingress to do a smart placement of the ELI/EL to make it readable for the tail-end. Even if the ERLD is leaked, there is still no insurance that the ingress will be able to set an ELI/EL at a readable place for the tail-end. Its MSD may prevent that.
This means that the value associated with the ERLD may be considered as a nice to have, while the ELC is mandatory. While, in the basic intraAS, single domain case, it’s easy to provide the ERLD and as you mentioned, we can also do it on a multi-area case, we could consider that the multiprotocol case will lack of ERLD, if everyone agrees on that. This does not prevent to use EL but may not the loadbalancing will not be as efficient as it could be with ERLD.
We cannot really mandate to deploy a controller to do that, introducing a controller is a big network change.

[SLI3] My point was just to say in the draft that this problem is out of scope. But at least we agree that there is something to discuss apart of this document.

Binding SID:

A is the ingress node.

[Les2:] A is trying to setup an LSP from A->G. As such, A should only be interested in ELC of G.
[SLI3] IMO that’s not true. It is true for an LDP or RSVP LSP but not for SRTE. From an MPLS point of view, an SRTE LSP is a combination of multiple nested LSPs. Each “sub-LSP” (each segment) has it’s own tail-end and so it’s own ELC. That’s why the ingress is able to insert an ELI/EL anywhere in the stack as far as the tail-end of the associated subLSP is ELC.

The fact that C may insert an “inner LSP” to F should be irrelevant to A. But I take your point that there are two possible behaviors on C and at the moment which behavior is expected is not specified.
[SLI3] You are completely right here and I’m not challenging this point. My point was to say that if A inserts an ELI/EL next to a BSID, it must ensure the ELC.

Or

I prefer #2 – it means the introduction of BSID does not change existing EL behavior. But I am interested in what other folks think.
[SLI3] I’m also in favor of this option, but this requires a propagation of the tail-end’s ELC of the BSID LSP as part of the BSID advertisement.

  Les

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 Aug 2018 15:27:33 +0000

Hi Tiger, Bruno,

Or would this be better?

       “The advertisement and discovery of the complete LSP path topology in inter-AS and inter-protocol scenarios is outside the scope of this document.”

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Xiaohu (Tiger) Xu" <[email-masked]>
Reply-To: "Xiaohu (Tiger) Xu" <[email-masked]>
Date: Friday, August 10, 2018 at 2:20 AM
To: Lsr <[email-masked]>, Stephane Litkowski <[email-masked]>, Gunter Van de Velde <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 27 Aug 2018 14:57:22 +0000

Hi Acee,

Thanks for the suggestion.
Contrary to MSD, ELC does not require the knowledge of the path topology. Hence I don’t think this is helpful to refer to LSP path topology.

Tiger’s proposal could work for me, but I personally think it would be fair and clearer to clearly state that the proposal does not provide a solution for inter-AS and inter-protocol deployments.
e.g. “The advertisement of ELC in Inter-AS and inter-protocol scenarios is not supported.”

Thanks,
Regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, August 15, 2018 5:28 PM
To: ???(??); Lsr; LITKOWSKI Stephane OBS/OINIS; Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Tiger, Bruno,

Or would this be better?

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Aug 2018 18:22:46 +0000

Hi Bruno,

From: Bruno Decraene <[email-masked]>
Date: Monday, August 27, 2018 at 10:57 AM
To: Acee Lindem <[email-masked]>, "Xiaohu (Tiger) Xu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Lsr <[email-masked]>, Stephane Litkowski <[email-masked]>, Gunter Van de Velde <[email-masked]>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Acee,

I’m fine with that.
Thanks,
Acee

Thanks,
Regards,
--Bruno

Hi Tiger, Bruno,

Or would this be better?

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 29 Aug 2018 10:00:04 +0800

Hi Acee and Bruno,

Thanks a lot for your valuable comments and suggestions. I will add the following text into the next revision:

"When the ELC advertisement originated by a router in one area is propagated to another area in the inter-area scenario, those routers in the latter area need to find the routable IP addresses of the router originating that ELC advertisement before inserting the Entropy Label (EL) for packets going to the Label Switch Path (LSP) tunnel towards one of the above routable IP addresses. How to find the correlation between the Router-ID and the routable IP address of a given router is outside the scope of this document. In addition, the advertisement of ELC in inter-AS and inter-protocol scenarios is not supported".

Best regards,
Xiaohu
------------------------------------------------------------------
From:Acee Lindem (acee) <acee=[email-masked]>
Send Time:2018年8月29日(星期三) 02:23
To:[email-masked] <[email-masked]>; 徐小虎(义先) <[email-masked]>
Cc:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>; "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>; Lsr <[email-masked]>; LITKOWSKI Stephane OBS/OINIS <[email-masked]>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Bruno, 

Hi Acee,

I’m fine with that. 
Thanks,
Acee 

Thanks,
Regards,
--Bruno

Or would this be better? 

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

 Thanks,
 Regards,
 --Bruno

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Aug 2018 11:22:39 +0000

Hi Tiger,
I guess I don’t understand the explicit requirement for a routable address. When is the LSP or segment egress not a routable address?
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Xiaohu (Tiger) Xu" <[email-masked]>
Reply-To: "Xiaohu (Tiger) Xu" <[email-masked]>
Date: Tuesday, August 28, 2018 at 10:00 PM
To: Lsr <[email-masked]>, Bruno Decraene <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, Lsr <[email-masked]>, Gunter Van de Velde <[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Acee and Bruno,

Best regards,
Xiaohu

Hi Bruno,

Hi Acee,

I’m fine with that.
Thanks,
Acee

Thanks,
Regards,
--Bruno

Hi Tiger, Bruno,

Or would this be better?

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 30 Aug 2018 09:01:07 +0800

Hi Acee,

What I had wanted to say is "the routers in one area need to find the correlation between the router ID and the routable addresses of a given router within another area which had originated an ELC advertisement across areas". How about simply saying "how to use the ELC advertisement in the inter-area scenario is outside the scope of this document"?

Best regards,
Tiger

------------------------------------------------------------------
From:Acee Lindem (acee) <acee=[email-masked]>
Send Time:2018年8月29日(星期三) 19:23
To:徐小虎(义先) <[email-masked]>; Lsr <[email-masked]>; [email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>; "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>; LITKOWSKI Stephane OBS/OINIS <[email-masked]>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Tiger, 

Hi Acee and Bruno,

Best regards,
Xiaohu

Hi Bruno, 

Hi Acee,

I’m fine with that. 
Thanks,
Acee 

Thanks,
Regards,
--Bruno

Hi Tiger, Bruno, 

Or would this be better? 

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

 Thanks,
 Regards,
 --Bruno

---

From: <[email-masked]>
Date: Thu, 30 Aug 2018 09:25:59 +0000

Commenting on myself [Bruno]

From: DECRAENE Bruno IMT/OLN
Sent: Monday, August 27, 2018 4:57 PM

Hi Acee,

[Bruno] Sorry, I meant :s/MSD/ERLD (Entropy Readable Label Depth)

[Bruno] To clarify my position:
- I believe that draft-ietf-isis-mpls-elc should support the use/advertisement of EL in SR-MPLS inter-area/AS/protocol deployments, in order to avoid regressions compared to LDP.
- In the meantime, I think the document should explicitly state that it does not support it (in its current version), in order to raise awareness of this limit

Thanks,
Regards,
--Bruno

Hi Tiger, Bruno,

Or would this be better?

Thanks,
Acee

Bruno,

Best regards,
Xiaohu

Xiaohu,

Best regards,

Stephane –

Hi Gunter,

Multiarea case:

Multiprotocol case:

Binding SID:

   Les

Brgds,

Stephane

“

G/

Hi,

Hi Les, Bruno,

Bruno –

Inline.

Les,

Bruno –

    Les

Thanks,
Regards,
--Bruno

   Les

Hi  Xiaohu,

Thanks for the reply.

Thanks
Best regards,
--Bruno

Hi Bruno,

Best regards,
Xiaohu

Hi authors,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.