Aijun �C
In the inter-AS case, what is needed is to know ELC of the originating node.
Simply knowing who the originator of an advertisement is not sufficient.
If ELC is advertised as a node capability, then a controller with access to
BGP-LS database for both ASs could determine ELC by piecing together the node
capability advertisement and the prefix advertisement w originating router-id.
But what Stephane has proposed for the inter-AS case is a way to know ELC in
the absence of a controller.
This means nodes in AS #1 need to have ELC capability info for nodes in AS #2.
As there is no way to redistribute IGP Node Capability advertisements between
different IGP instances, the alternative is to advertise ELC associated with a
prefix advertisement since the prefix advertisement can be redistributed
between IGP instances.
Knowing the originator of the prefix is necessary, but it is not sufficient.
Hope this is clear.
Les
From: Aijun Wang <[email protected]>
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) <[email protected]>;
[email protected]; [email protected]
Cc: [email protected]
Subject: 答复: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi, Les and Stephane:
https://tools.ietf.org/html/draft-wang-lsr-ospf-prefix-originator-ext-00 is
trying to solve what you are concerning for.
As you said, ELC/ERLD are functionally node capabilities, but when we try to
send traffic, we should consider the prefixes itself.
The above draft proposal to add prefix originator to address this. After
getting this information, the receiver can then build the relationship between
prefixes and ELC/ERLD.
Best Regards.
Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Les Ginsberg (ginsberg) [mailto:[email protected]]
发送时间: 2018年11月20日 2:00
收件人: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
抄送: [email protected]<mailto:[email protected]>
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Stephane �C
The use case for this proposal is to support inter-AS scenarios in the absence
of a controller.
If the WG agrees that this use case needs to be addressed I believe the
proposal below is a good and viable compromise.
I say “compromise” because �C as you mention below �C ELC/ELRD are functionally
node capabilities. But the inter-AS use case requires signaling between AS’s
and the vehicle we have for doing that is a prefix advertisement. The
compromise is to advertise ELC associated with a prefix �C but not do so for
ERLD.
This seems reasonable to me.
One change to what you state below �C I think “when a prefix is leaked or
redistributed, the ELC associated to the prefix MUST also be
leaked/redistributed.”.
Les
From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Friday, November 09, 2018 6:30 AM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi WG,
Some discussions occurred on the mailing list on how to encode the entropy
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have
participated to this discussion.
Following this discussion, we are coming with the following proposal that the
WG need to validate:
The entropy label capability is still considered as a per node property (for
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not
want to have an ERLD per linecard).
However IGPs may advertise prefixes that are not belonging to the node itself
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.
When an ingress node pushes an entropy label below a segment it must ensure
that the tail-end of the segment is entropy label capable otherwise packets
will be dropped.
As a consequence, when prefixes are redistributed, the entropy label capability
of the node who has firstly originated the prefix, should be associated to the
prefix during the redistribution.
In terms of encoding, we propose to associate an entropy label capability for
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by
a local configuration and for leaked/redistributed prefixes. When a prefix is
leaked or redistributed, the ELC associated to the prefix may be also
leaked/redistributed.
An ingress should set the entropy label below a Node/Prefix segment only if the
prefix associated to the Node/Prefix segment as the ELC set in the Prefix
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the
adjacent neighbor of the node that has advertised the Adj SID is advertising an
ERLD (and so is entropy label capable).
For the binding SID, as IGPs are not involved in the signaling of the binding
SID, there is nothing to do in these drafts.
Let us know your comments/feedback on this proposal so we can progress these
documents.
Brgds,
Stephane
_________________________________________________________________________________________________________________________
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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
