[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] [OSPF] =?UTF-8?B?562U5aSN?=: WG Last Call for "Signalling ELC using OSPF"
From: Jeff Tantsura <jefftant.ietf () gmail ! com>
Date: 2016-11-14 1:20:24
Message-ID: 1593BDB8-6AFA-41BB-A8A8-6EB0A02A86FF () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I support Acee's position.
Cheers,
Jeff
From: mpls <mpls-bounces@ietf.org> on behalf of "Acee Lindem (acee)" <acee@cisco.com>
Date: Saturday, November 12, 2016 at 14:08
To: Xuxiaohu <xuxiaohu@huawei.com>, "bruno.decraene@orange.com" \
<bruno.decraene@orange.com>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"
Hi Tiger, other authors,
So, this is my take on the draft information content based on the comments from \
Carlos and Bruno.
1. The standards track IGP drafts should have a precise definition of RLD and so \
not require a normative reference to the MPLS entropy draft (which is informational). \
The IGP drafts need not precisely specify how the information is used - this can be \
specified via a reference to the MPLS draft.
2. The MPLS draft should precisely specify the initial use case of entropy label \
insertion at the ingress of the LSP. It should not limit the applicability of RLDC to \
this use case.
Thanks,
Acee
From: OSPF <ospf-bounces@ietf.org> on behalf of Xiaohu Xu <xuxiaohu@huawei.com>
Date: Friday, November 11, 2016 at 5:10 AM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: OSPF WG List <ospf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "Carlos Pignataro \
(cpignata)" <cpignata@cisco.com>
Subject: [OSPF] 答复: WG Last Call for "Signalling ELC using OSPF"
Hi Bruno,
发件人: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
发送时间: 2016年11月10日 21:31
收件人: Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata); mpls@ietf.org
主题: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi Xuxiaohu,
The RLDC specification(s) needs to be clear enough such that:
- transit LSR knows what to advertise
[Xiaohu] LSRs advertise how many labels they could read from the top of the label \
stack. LSRs can advertise this information no matter whether or not they support \
EL-based LB.
- ingress LSR knows how to use it in order to achieve/optimize load balancing across \
the MPLS network.
[Xiaohu] This draft only describes how to advertise the RLDC via IGP. As for how to \
use this information by ingress LSRs when inserting EL pairs, it's discussed in \
Section 4 of draft-ietf-mpls-spring-entropy-label-04.
Best regards,
Xiaohu
So let's start with the first question: which RLDC value should be advertised by such \
transit LSR? (cf below) And please quote the text from the RDLC spec which supports \
the answer.
> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> However, it seems that it has nothing to do with the EL-based MPLS load-balancing \
> mechanism.
AFAIK, EL is defined in RFC6790, which defines a new behavior on the egress and \
ingress. It does not standardize the load-balancing behavior on transit nodes which \
are mostly free to do any load-balancing behavior. So it looks like hard to define an \
IGP TLV to advertise this non-standardized behavior, which is largely independent of \
the EL specification. IOW to re-use your terms, there is no such EL-based MPLS \
load-balancing specification for transit LSR.
https://tools.ietf.org/html/rfc6790#section-4.3
Now, we (MPLS WG) can try to model the load-balancing behavior of MPLS LSR, so that \
we (IGP WG) can latter advertise the parameters of this model in the IGP. But from \
what I can see in existing product, the current RLDC seems insufficient to model the \
behavior of existing MPLS LSR.
The current RLDC advertisement seems to be able to model a very small subset: a \
transit LSR which recognizes the ELI, and load balance solely on the following label \
(the EL).
If so,
- this need to be clear in the RLDC specification, because currently this is not.
- this may be seen as an incremental improvement but I don't believe that it really \
solves the problem, nor significantly improve it given the behavior of existing \
plateform.
I'd rather have a solution which is more generally applicable and provide a \
significant improvement. i.e. model the load-balancing behavior of most current and \
future MPLS LSR, and then advertise the parameters in the IGP. (including a model ID \
such that this can be improved in the future). I agree that this is more complex job.
Thanks,
Best regards,
Bruno
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Thursday, November 10, 2016 10:58 AM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF WG List; Carlos Pignataro (cpignata); mpls@ietf.org
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi Bruno,
Thanks for sharing the following information. However, it seems that it has nothing \
to do with the EL-based MPLS load-balancing mechanism. The ELC and RLDC as described \
in draft-ietf-ospf-mpls-elc are applicable to the EL-based MPLS load-balancing \
mechanism.
Best regards,
Xiaohu
发件人:bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
发送时间: 2016年11月10日 16:56
收件人: Xuxiaohu
抄送: OSPF WG List; Carlos Pignataro (cpignata)
主题: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi all,
(Hopefully) For the benefit of the discussion, I'm sharing a real world MPLS (transit \
LSR) load balancing algo on one plateform:
Label <=3: 2-tuple <source IP(rightmost 30bit), destination IP (rightmost 30bit)>
Label = 4: bottom-of-stack label (rightmost 20bit)
Label>=5: Fifth(rightmost 20bit) label from the top
This is a more or less random pick, and in general the behaviors are very diverse \
depending on the plateform (router, line card, os version, MPLS encapsulated \
traffic).
In general, it's not clear to me how the RLDC advertisement really helps the ingress \
to make an informed decision and improve the load balancing of its flow across the \
MPLS network, as the current advertisement seems a bit simplistic to me.
More specifically, with the current definition of the RLDC, it's hard for me to guess \
which RLDC value should be advertised. So I would really expect interop issues and \
endless discussion about who is right.
Thanks,
Regards,
-- Bruno
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: Thursday, November 10, 2016 5:29 AM
To: Carlos Pignataro (cpignata); DECRAENE Bruno IMT/OLN
Cc: OSPF WG List
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi Carlos,
Thanks for your comments. Please see my response inline.
发件人: OSPF [mailto:ospf-bounces@ietf.org] 代表 Carlos Pignataro (cpignata)
发送时间: 2016年11月8日 23:20
收件人: Bruno Decraene
抄送: OSPF WG List
主题: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Jumping a bit mid-thread, but with somewhat similar or related comments.
Summary: I am concerned with the lack of precision in the definitions and usage on \
these set of documents.
Acee, if this document needs to depend on Section 4 of \
draft-ietf-mpls-spring-entropy-label-04.txt, then the issue is compounded. I believe \
draft-ietf-mpls-spring-entropy-label-04has its own set of problems (for example, \
placing EL/ELI independent of whether the underlying Label is for a Node SID or a \
Segment SID is not optimum).
So the main question is: Is draft-ietf-ospf-mpls-elc-03 to be treated independently \
form draft-ietf-mpls-spring-entropy-label-04? That is a fundamental question for \
advancing and reviewing this/these doc(s). We have the advertisement of a capability \
— what is it used for? Is it the right variable to advertise (based on the \
application using it)?
[Xiaohu] draft-ietf-ospf-mpls-elc-03 defines an approach of advertising the RLDC of \
an LSR via OSPF. The definition of the RLDC is described in the following text (i.e., \
each LSR's capability of reading the maximum label stack depth). As for how to use \
this capability, it's not limited by the draft although one use case (i.e., the \
application as described in Section 4 of draft-ietf-mpls-spring-entropy-label-04.txt) \
is mentioned in this draft.
Specifically, I think that RLDC is largely underspecified. The doc says:
"
it would be useful for ingress LSRs to know each LSR's capability of
reading the maximum label stack deepth. This capability, referred to
as Readable Label Deepth Capability (RLDC)
"
That definition simple does not make sense. And it does not explain the applicability \
(A, b, c, d).
[Xiaohu]Could you speak more specifically? Is the definition of the RLDC (i.e., what \
is the capability of reading the maximum label stack depth) itself not clear enough? \
If so, could you please suggestion any more specific text? Or the applicability of \
the RLDC not clear enough? If so, we co-authors currently only think about one use \
case of this RLDC that is described in Section 4 of \
draft-ietf-mpls-spring-entropy-label-04.txt) , please feel free to tell us if you \
find any other use cases of this RLDC.
Then the doc continues:
"
Readable Label Deepth Capability (RLDC) can be used by ingress
LSRs to determine whether it's necessary to insert an EL for a given
LSP tunnel in the case where there has already been at least one EL
in the label stack [I-D.ietf-mpls-spring-entropy-label] .
"
So this only is useful when there's an EL (I assume ELI/EL pair) already?
[Xiaohu] In the EL insertion use case, yes, your understand is correct.
And is "[I-D.ietf-mpls-spring-entropy-label]" normative?
[Xiaohu] Currently yes, if it's widely believed that this reference should be \
informational, it can be moved to the informational reference section.
Overall, I think a WGLC is premature, since some basics are not well covered. Is it \
RLD or RLDC? And what exactly is a "Readable Label Deepth Capability (RLDC)" The \
capability to do what? Is this a Capability or a scalar?
[Xiaohu] RLDC (Readable Label Deeth Capability) means a given LSR's capability of \
reading the maximum label stack depth. If it's widely believed that "RLD" is more \
suitable than "RLDC" from the expression perspective, it's fine to make a change.
Another point comment — although I think this needs a thorough review before WGLC.
The doc says:
Of course,
even it has been determined that it's neccessary to insert an EL for
a given LSP tunnel, if the egress LSR of that LSP tunnel has not yet
indicated that it can process ELs for that tunnel, the ingress LSR
MUST NOT include an entropy label for that tunnel as well.
This is good and consistent with RFC 6790:
c. X MUST NOT include an entropy label for a given tunnel unless the
egress LSR Y has indicated that it can process entropy labels for
that tunnel.
So it's better to point to it instead of re-MUST NOT independently.
[Xiaohu] Good suggestion. Will fix it.
But, what is the egress of a tunnel in this context? Not the final egress, but the \
SID egress. ?
[Xiaohu] IMHO, the egress of an LSP tunnel is clear enough and easy to understand. In \
contrast, what's the mean of SID egress, could you please help point to a reference \
for this term defincation?
Best regards,
Xiaohu
Thanks,
—
Carlos Pignataro, carlos@cisco.com
"Sometimes I use big words that I do not fully understand, to make myself sound more \
photosynthesis."
On Nov 8, 2016, at 6:15 AM, bruno.decraene@orange.com wrote:
Hi Acee,
Thanks for your reply. Please see inline [Bruno]
From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, November 08, 2016 2:27 AM
To: DECRAENE Bruno IMT/OLN; OSPF WG List
Subject: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi Bruno,
From: Bruno Decraene <bruno.decraene@orange.com>
Date: Monday, November 7, 2016 at 6:43 AM
To: Acee Lindem <acee@cisco.com>, OSPF WG List <ospf@ietf.org>
Subject: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"
Hi authors, all,
Please find below some comments on the RLDC definition.
1) I'd like to see a more specific definition of RLDC.
e.g. load-balancing hashing could be done based on (hashing):
-a- a (stack of) N "regular" MPLS labels (i.e. there is no ELI in this stack)
-b- the (IP) header below the stack of N labels
-c- the EL label in the stack of N labels (i.e. there is one ELI in this stack)
I'd like the specification to be clear on the applicability of the RLDC. Does it \
apply on these 3 cases, on only a subset?
Personally, I'd like at least a and c be in scope of the RLDC definition, such that \
an ingress with limited push capability could have enough information to decide that \
it could avoid pushing an ELI,EL pair if the stack of MPLS labels that it pushes has \
enough entropy within the first RLDC labels.
I think that the signaling document should reference section 4 of \
https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. However, I don't \
think -b- is covered there.
[Bruno] The above section 4 has indeed more details, but I'm not certain that the \
definition is clear enough for everyone to agree on which "a", "b", "c" cases are \
covered by the RLDC advertisement. My reading would be that "a" and "c" are covered, \
not "b". Reading your email, I'd say that you have the same understanding. But it \
bothers me that one of the authors has a different understanding.
Alsodraft-ietf-mpls-spring-entropy-label-04.txt is an informational document, so I'm \
not sure how much it would qualify to be a normative definition of what \
draft-ietf-ospf-mpls-elc advertise.
Thanks,
Regards,
-- Bruno
2) Current text seems to limit the use of the RLDC to the insertion of a _second_ EL. \
Why is the RLD not applicable to the first EL?
1. Introduction
"This capability, referred to
as Readable Label Deepth Capability (RLDC) can be used by ingress
LSRs to determine whether it's necessary to insert an EL for a given
LSP tunnel in the case where there has already been at least one EL
in the label stack [I-D.ietf-mpls-spring-entropy-label]"
6 Usage and Applicability
"The RLDC is used by ingress LSRs
to determine whether it's necessary to insert an EL for a given LSP
tunnel in the case where there has already been at least one EL in
the label stack.
I think that this is an unnecessary restriction of the RLDC usage. Indeed, an ingress \
with a limited capability in term of label push, could be forced to push a single EL \
label. It should be able to use the RLDC info in order to choose the best location \
for the EL, even if it pushes a single one.
But both sentences seems to restrict RLDC usage for the additional EL push, not the \
first one.
I would tend to agree.
Thanks,
Acee
Thanks,
Regards,
--Bruno
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, November 05, 2016 5:46 PM
To: OSPF WG List
Subject: [OSPF] WG Last Call for "Signalling ELC using OSPF"
This begins the WG last call for "Signalling ELC using OSPF", \
https://www.ietf.org/id/draft-ietf-ospf-mpls-elc-03.txt. Please review the document \
and send comments to this list prior to Nov 27th, 2016. Due to the IETF week, the \
last call period is going to be 3 weeks rather than usual 2 weeks.
Thanks,
Acee
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou \
privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans \
autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a \
l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques \
etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a \
ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information \
that may be protected by law; they should not be distributed, used or copied without \
authorisation. If you have received this email in error, please notify the sender and \
delete this message and its attachments. As emails may be altered, Orange is not \
liable for messages that have been modified, changed or falsified. Thank you.
_________________________________________________________________________________________________________________________
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.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou \
privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans \
autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a \
l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques \
etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a \
ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information \
that may be protected by law; they should not be distributed, 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.
_________________________________________________________________________________________________________________________
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 mpls@ietf.org \
https://www.ietf.org/mailman/listinfo/mpls
[Attachment #5 (text/html)]
<html xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Title content=""><meta \
name=Keywords content=""><meta http-equiv=Content-Type content="text/html; \
charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered \
medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:宋体;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Courier;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:Calibri;}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:"Courier New";}
p.PrformatHTML, li.PrformatHTML, div.PrformatHTML
{mso-style-name:"Préformaté HTML";
mso-style-link:"Préformaté HTML Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.TextedebullesCar
{mso-style-name:"Texte de bulles Car";
mso-style-priority:99;
mso-style-link:"Texte de bulles";
font-family:Tahoma;}
p.Textedebulles, li.Textedebulles, div.Textedebulles
{mso-style-name:"Texte de bulles";
mso-style-link:"Texte de bulles Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
p.HTML, li.HTML, div.HTML
{mso-style-name:"HTML 预设 式";
mso-style-link:"HTML 预设 式 Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.HTMLChar
{mso-style-name:"HTML 预设 式 Char";
mso-style-priority:99;
mso-style-link:"HTML 预设 式";
font-family:"Courier New";}
p.a, li.a, div.a
{mso-style-name:批注框文本;
mso-style-link:"批注框文本 Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.Char
{mso-style-name:"批注框文本 Char";
mso-style-priority:99;
mso-style-link:批注框文本;
font-family:宋体;}
span.EmailStyle29
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle30
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle31
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle32
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle33
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle34
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle35
{mso-style-type:personal;
font-family:Calibri;
color:#1F497D;}
span.EmailStyle36
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri'>I support Acee’s \
position.<o:p></o:p></span></p><div><p class=MsoNormal><span \
style='font-size:10.5pt;font-family:Calibri;color:black'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:10.5pt;font-family:Calibri;color:black'>Cheers,<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:10.5pt;font-family:Calibri;color:black'>Jeff<o:p></o:p></span></p></div><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri'><o:p> </o:p></span></p><div \
style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p \
class=MsoNormal><b><span style='font-family:Calibri;color:black'>From: \
</span></b><span style='font-family:Calibri;color:black'>mpls \
<mpls-bounces@ietf.org> on behalf of "Acee Lindem (acee)" \
<acee@cisco.com><br><b>Date: </b>Saturday, November 12, 2016 at 14:08<br><b>To: \
</b>Xuxiaohu <xuxiaohu@huawei.com>, "bruno.decraene@orange.com" \
<bruno.decraene@orange.com><br><b>Cc: </b>"ospf@ietf.org" \
<ospf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org><br><b>Subject: \
</b>Re: [mpls] [OSPF] </span><span style='font-family:"MS \
Mincho";color:black'>答复</span><span style='font-family:Calibri;color:black'>: WG \
Last Call for "Signalling ELC using \
OSPF"<o:p></o:p></span></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi Tiger, other \
authors, <o:p></o:p></p></div><div><p class=MsoNormal>So, this is my take on the \
draft information content based on the comments from Carlos and \
Bruno. <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> 1. \
The standards track IGP drafts should have a precise definition of RLD and so not \
require a normative reference to the MPLS entropy draft (which is informational). The \
IGP drafts need not precisely specify how the information is used - this can be \
specified via a reference to the MPLS draft. <o:p></o:p></p></div><div><p \
class=MsoNormal> 2. The MPLS draft should precisely specify the initial \
use case of entropy label insertion at the ingress of the LSP. It should not limit \
the applicability of RLDC to this use case. <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p \
class=MsoNormal>Acee<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div style='border:none;border-top:solid \
#B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span \
style='font-size:11.0pt;font-family:Calibri;color:black'>From: </span></b><span \
style='font-size:11.0pt;font-family:Calibri;color:black'>OSPF <<a \
href="mailto:ospf-bounces@ietf.org">ospf-bounces@ietf.org</a>> on behalf of Xiaohu \
Xu <<a href="mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com</a>><br><b>Date: \
</b>Friday, November 11, 2016 at 5:10 AM<br><b>To: </b>Bruno Decraene <<a \
href="mailto:bruno.decraene@orange.com">bruno.decraene@orange.com</a>><br><b>Cc: \
</b>OSPF WG List <<a href="mailto:ospf@ietf.org">ospf@ietf.org</a>>, "<a \
href="mailto:mpls@ietf.org">mpls@ietf.org</a>" <<a \
href="mailto:mpls@ietf.org">mpls@ietf.org</a>>, "Carlos Pignataro \
(cpignata)" <<a \
href="mailto:cpignata@cisco.com">cpignata@cisco.com</a>><br><b>Subject: </b>[OSPF] \
</span><span style='font-size:11.0pt;font-family:"MS \
Mincho";color:black'>答复</span><span \
style='font-size:11.0pt;font-family:Calibri;color:black'>: WG Last Call for \
"Signalling ELC using OSPF"<o:p></o:p></span></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><blockquote \
style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in \
4.0pt;margin-left:3.75pt;margin-right:0in' \
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><div><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Hi \
Bruno,</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><div \
style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div \
style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p \
class=MsoNormal><b><span lang=ZH-CN \
style='font-size:10.0pt;font-family:宋体;mso-fareast-language:ZH-CN'>发件人</span></b><b><span \
style='font-size:10.0pt;font-family:宋体;mso-fareast-language:ZH-CN'>:</span></b><span \
style='font-size:10.0pt;font-family:宋体;mso-fareast-language:ZH-CN'> <a \
href="mailto:bruno.decraene@orange.com">bruno.decraene@orange.com</a> [<a \
href="mailto:bruno.decraene@orange.com">mailto:bruno.decraene@orange.com</a>] \
<br><b><span lang=ZH-CN>发送时间</span>:</b> 2016<span \
lang=ZH-CN>年</span>11<span lang=ZH-CN>月</span>10<span lang=ZH-CN>日</span> \
21:31<br><b><span lang=ZH-CN>收件人</span>:</b> Xuxiaohu<br><b><span \
lang=ZH-CN>抄送</span>:</b> OSPF WG List; Carlos Pignataro (cpignata); <a \
href="mailto:mpls@ietf.org">mpls@ietf.org</a><br><b><span \
lang=ZH-CN>主题</span>:</b> RE: [OSPF] WG Last Call for "Signalling ELC using \
OSPF"</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p></div></div><p \
class=MsoNormal><span \
style='mso-fareast-language:ZH-CN'> <o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Hi \
Xuxiaohu,</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>The \
RLDC specification(s) needs to be clear enough such that:</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>- \
transit LSR knows what to advertise</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>[Xiaohu] \
LSRs advertise how many labels they could read from the top of the label stack. LSRs \
can advertise this information no matter whether or not they support EL-based \
LB.</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>- \
ingress LSR knows how to use it in order to achieve/optimize load balancing across \
the MPLS network.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>[Xiaohu] \
This draft only describes how to advertise the RLDC via IGP. As for how to use this \
information by ingress LSRs when inserting EL pairs, it’s discussed in Section \
4 of draft-ietf-mpls-spring-entropy-label-04.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Best \
regards,</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:16.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Xiaohu</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>So \
let’s start with the first question: which RLDC value should be advertised by \
such transit LSR? (cf below) And please quote the text from the RDLC spec which \
supports the answer.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:Tahoma;mso-fareast-language:ZH-CN'>> \
From:</span></b><span \
style='font-size:10.0pt;font-family:Tahoma;mso-fareast-language:ZH-CN'> Xuxiaohu [<a \
href="mailto:xuxiaohu@huawei.com">mailto:xuxiaohu@huawei.com</a>]</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>> \
However, it seems that it has nothing to do with the EL-based MPLS load-balancing \
mechanism.</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>AFAIK, \
EL is defined in RFC6790, which defines a new behavior on the egress and ingress. It \
does not standardize the load-balancing behavior on transit nodes which are mostly \
free to do any load-balancing behavior. So it looks like hard to define an IGP TLV to \
advertise this non-standardized behavior, which is largely independent of the EL \
specification. IOW to re-use your terms, there is no such EL-based MPLS \
load-balancing specification for transit LSR.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'><a \
href="https://tools.ietf.org/html/rfc6790#section-4.3">https://tools.ietf.org/html/rfc6790#section-4.3</a></span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Now, \
we (MPLS WG) can try to model the load-balancing behavior of MPLS LSR, so that we \
(IGP WG) can latter advertise the parameters of this model in the IGP. But from what \
I can see in existing product, the current RLDC seems insufficient to model the \
behavior of existing MPLS LSR.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>The \
current RLDC advertisement seems to be able to model a very small subset: a transit \
LSR which recognizes the ELI, and load balance solely on the following label (the \
EL).</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>If \
so,</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>- \
this need to be clear in the RLDC specification, because currently this is \
not.</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>- \
this may be seen as an incremental improvement but I don’t believe that it \
really solves the problem, nor significantly improve it given the behavior of \
existing plateform.</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>I’d \
rather have a solution which is more generally applicable and provide a significant \
improvement. i.e. model the load-balancing behavior of most current and future MPLS \
LSR, and then advertise the parameters in the IGP. (including a model ID such that \
this can be improved in the future). I agree that this is more complex \
job.</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Thanks,</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Best \
regards,</span><span style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'>Bruno</span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;mso-fareast-language:ZH-CN'> </span><span \
style='mso-fareast-language:ZH-CN'><o:p></o:p></span></p><div \
style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div \
style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p \
class=MsoNormal><b><span lang=FR \
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic