Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-06 Thread stephane.litkowski 
[Xiaohu] Yes there is no need for them to advertise the ELC. However, there is 
a need for them to advertise the capability of reading the maximum label stack 
depth and performing EL-based load-balancing, if I understood it correctly. 
IMHO, it seems better that the ELC and the ERLD are defined as two independent 
capabilities, in other words, the ERLD semantics should not include the ELC 
semantics (i.e., the first requirement should be removed).

[SLI] If you want to benefit of entropy in a SPRING network, all routers should 
be ELC as any router may be an egress LSR for a particular segment. There was a 
strong consensus on having ELC as part of the ERLD. So even if from a 
theoretical point of view, pure LSRs for a Node-SID may not have to be ELC, 
they could be used as egress for other segments, so they need to be ELC.

From: 徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Friday, July 06, 2018 03:04
To: LITKOWSKI Stephane OBS/OINIS; m...@ietf.org
Cc: l...@ietf.org; pce@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label


Hi Stephane,

Thanks for your reply. Please see my response inline with [Xiaohu]
--
From:stephane.litkowski 
Send Time:2018年7月6日(星期五) 06:19
To:徐小虎(义先) ; m...@ietf.org 
Cc:l...@ietf.org ; pce@ietf.org 
Subject:RE: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi,

Thanks for your comment.
Pls find some inline replies

Brgds,

Stephane

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, July 05, 2018 05:34
To: m...@ietf.org
Cc: l...@ietf.org; pce@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi all,

I have the following comments and hope it' s not too late.

1. In fact, RFC6790 doesn't require intermediate routers to have the capability 
of performing EL-based load-balancing mechanism. Instead, it just provides an 
entropy in the MPLS packet which may be available for intermediate routers to 
perform load-balancing.  In contrast, the recommended approach as defined in 
draft-ietf-mpls-spring-entropy-label requires the ingress of a given SR-TE path 
to take into account the ERLD capability of all intermediate routers on that 
path. However, in the loose explicit route case, those intermediate routers 
that the explicit path traverses may change over time due to IGP convergence or 
there may exist multiple ECMPs from one segment towards the next segment. That 
would make the ELI/EI imposition decision much complex. I personally believe 
that the principle used in RFC6790 would make the implementation and deployment 
much easier and therefore should be kept.

[SLI] Using SRTE and label stacking is not different from nested LSP. Each 
tail-end of a segment should be ELC to ensure that it can pop the ELI/EL if the 
ingress decides to push it. The current text does not mandate anything 
regarding the analysis of transit nodes. It says without using normative 
language that the implementation may try to find the minimum ERLD along the 
path. But behaving as RFC6790 is for sure simpler and is compliant.

[Xiaohu] If so, I wonder whether it should be Informational rather than 
Standard Track?


2. It said in section 4 that "

   The Entropy Readable Label Depth (ERLD) is defined as the number of

   labels a router can both:



   a.  Read in an MPLS packet received on its incoming interface(s)

   (starting from the top of the stack).



   b.  Use in its load-balancing function.
:

However, it said later that:


 To advertise an ERLD value, a SPRING router:



   o  MUST be entropy label capable and, as a consequence, MUST apply

  the dataplane procedures defined in 
[RFC6790].



   o  MUST be able to read an ELI/EL which is located within its ERLD

  value.



   o  MUST take into account this EL in its load-balancing function.

Why should intermediate routers be required to meet the first requirement (e.g. 
the ELC as defined in RFC6790 ) if they would never be used as an LSP egress?
[SLI] If they are pure transit for a node SID, there is no need for them to 
advertise the ERLD.

[Xiaohu] Yes there is no need for them to advertise the ELC. However, there is 
a need for them to advertise the capability of reading the maximum label stack 
depth and performing EL-based load-balancing, if I understood it correctly. 
IMHO, it seems better that the ELC and the ERLD are defined as two independent 
capabilities, in other words, the ERLD semantics should not include the ELC 
semantics (i.e., the first requirement should be removed).

3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this

Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread Ketan Talaulikar (ketant) 
Hi Xiaohu,

The IGP drafts define MSD as a framework that enable advertisements for various 
type of SID limits – starting with the Base MSD Type – 1. You are referring to 
this generic construct of MSD in the text you quote below. It is, however, the 
Base MSD (type 1) which is aligned with the definition in PCEP-SR.

IMHO the PCEP-SR draft definition should be updated to refer to this base MSD 
type.

Thanks,
Ketan

From: mpls  On Behalf Of ???(??)
Sent: 06 July 2018 06:55
To: Jeff Tantsura ; stephane.litkowski 
; m...@ietf.org
Cc: l...@ietf.org; pce@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided 
by whatever protocol, the semantics of the MSD itself should be unified in the 
IETF community. Otherwise, it would introduce unnecessary confusion to 
implementors and operators.

It said in the OSPF-MSD draft：
"

   MSD: Maximum SID Depth - the number of SIDs a node or one of its

   links can support"



What does the "support" exactly mean? It seems at least to me a little bit 
ambiguous compared to the MSD concept as defined in the PCEP-SR draft.



Best regards,

Xiaohu




--
From:Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski 
mailto:stephane.litkow...@orange.com>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>; 
m...@ietf.org mailto:m...@ietf.org>>
Cc:l...@ietf.org mailto:l...@ietf.org>>; 
pce@ietf.org mailto:pce@ietf.org>>
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though.


3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this document) that a PCC is capable of

   imposing on a packet.



In the IGP-MSD draft, it said "

MSD of type 1 (IANA Registry), called Base MSD is used to signal the

   total number of SIDs a node is capable of imposing, to be used by a

   path computation element/controller.  "



If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_



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

Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread 徐小虎(义先) 
Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided 
by whatever protocol, the semantics of the MSD itself should be unified in the 
IETF community. Otherwise, it would introduce unnecessary confusion to 
implementors and operators.

It said in the OSPF-MSD draft：
"
   MSD: Maximum SID Depth - the number of SIDs a node or one of its
   links can support"

What does the "support" exactly mean? It seems at least to me a little bit 
ambiguous compared to the MSD concept as defined in the PCEP-SR draft.

Best regards,
Xiaohu
 



--
From:Jeff Tantsura 
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski ; 徐小虎(义先) 
; m...@ietf.org 
Cc:l...@ietf.org ; pce@ietf.org 
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label


Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though. 


3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.
 
In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "
 
If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition
ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”
OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:
“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu
_
 
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.
___ mpls mailing list m...@ietf.org 
https://www.ietf.org/mailman/listinfo/mpls

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

Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread Jeff Tantsura 
Hi,

 

Please see inline (MSD section).

Hope this clarifies, thanks!

 

Cheers,

Jeff

 

 

 

[jeff] both IGP drafts have identical description of the BMI-MSD:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”

PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).

However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though. 

 

 

3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.
 
In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "
 
If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?
 

[SLI] Today, the two IGP drafts does not seem to agree on the definition
ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all

   service/transport/special labels.”
OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation

   element/controller and is only relevant to the part of the stack

   created as the result of the computation.”

 

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:
“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in context of this document) that a PCC is capable of

   imposing on a packet.”

 

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.

 

 

 

Best regards,

Xiaohu
_
 
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.
___ mpls mailing list 
m...@ietf..org https://www.ietf.org/mailman/listinfo/mpls 

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

Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread stephane.litkowski 
Hi,

Thanks for your comment.
Pls find some inline replies

Brgds,

Stephane

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, July 05, 2018 05:34
To: m...@ietf.org
Cc: l...@ietf.org; pce@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi all,

I have the following comments and hope it' s not too late.

1. In fact, RFC6790 doesn't require intermediate routers to have the capability 
of performing EL-based load-balancing mechanism. Instead, it just provides an 
entropy in the MPLS packet which may be available for intermediate routers to 
perform load-balancing.  In contrast, the recommended approach as defined in 
draft-ietf-mpls-spring-entropy-label requires the ingress of a given SR-TE path 
to take into account the ERLD capability of all intermediate routers on that 
path. However, in the loose explicit route case, those intermediate routers 
that the explicit path traverses may change over time due to IGP convergence or 
there may exist multiple ECMPs from one segment towards the next segment. That 
would make the ELI/EI imposition decision much complex. I personally believe 
that the principle used in RFC6790 would make the implementation and deployment 
much easier and therefore should be kept.

[SLI] Using SRTE and label stacking is not different from nested LSP. Each 
tail-end of a segment should be ELC to ensure that it can pop the ELI/EL if the 
ingress decides to push it. The current text does not mandate anything 
regarding the analysis of transit nodes. It says without using normative 
language that the implementation may try to find the minimum ERLD along the 
path. But behaving as RFC6790 is for sure simpler and is compliant.


2. It said in section 4 that "

   The Entropy Readable Label Depth (ERLD) is defined as the number of

   labels a router can both:



   a.  Read in an MPLS packet received on its incoming interface(s)

   (starting from the top of the stack).



   b.  Use in its load-balancing function.
:

However, it said later that:


 To advertise an ERLD value, a SPRING router:



   o  MUST be entropy label capable and, as a consequence, MUST apply

  the dataplane procedures defined in 
[RFC6790].



   o  MUST be able to read an ELI/EL which is located within its ERLD

  value.



   o  MUST take into account this EL in its load-balancing function.

Why should intermediate routers be required to meet the first requirement (e.g. 
the ELC as defined in RFC6790 ) if they would never be used as an LSP egress?
[SLI] If they are pure transit for a node SID, there is no need for them to 
advertise the ERLD.

3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this document) that a PCC is capable of

   imposing on a packet.



In the IGP-MSD draft, it said "

MSD of type 1 (IANA Registry), called Base MSD is used to signal the

   total number of SIDs a node is capable of imposing, to be used by a

   path computation element/controller.  "



If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_

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