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)?
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).
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?
And is “[I-D.ietf-mpls-spring-entropy-label]” normative?
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?
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.
But, what is the egress of a tunnel in this context? Not the final egress, but
the SID egress. ?
Thanks,
—
Carlos Pignataro, [email protected]<mailto:[email protected]>
“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,
[email protected]<mailto:[email protected]> wrote:
Hi Acee,
Thanks for your reply. Please see inline [Bruno]
From: Acee Lindem (acee) [mailto:[email protected]]
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
<[email protected]<mailto:[email protected]>>
Date: Monday, November 7, 2016 at 6:43 AM
To: Acee Lindem <[email protected]<mailto:[email protected]>>, OSPF WG List
<[email protected]<mailto:[email protected]>>
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.
Also draft-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<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#ref-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:[email protected]] 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
