Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

From: <[email-masked]>
Date: Fri, 9 Nov 2018 14:30:19 +0000

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 19 Nov 2018 18:00:11 +0000

Stephane -

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 - as you mention below - 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 - but not do so for ERLD.
This seems reasonable to me.

One change to what you state below - I think "when a prefix is leaked or redistributed, the ELC associated to the prefix MUST also be leaked/redistributed.".

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, November 09, 2018 6:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Brgds,

Stephane

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 20 Nov 2018 10:16:23 +0800

Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence of a controller. If the inter-AS scenario is not for the TE purpose, would the (inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough (just like what we have done before in the LDP era, i.e., the BGP-initiated LSP over LDP-initiated LSP)?

Best regards,
Xiaohu

------------------------------------------------------------------
From:Les Ginsberg (ginsberg) <[email-masked]>
Send Time:2018年11月20日(星期二) 02:00
To:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

I say “compromise” because – as you mention below – 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 – but not do so for ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or redistributed, the ELC associated to the prefix MUST also be leaked/redistributed.”.

   Les

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.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 20 Nov 2018 14:41:25 +0800

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-masked]] 
发送时间: 2018年11月20日 2:00
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

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 – as you mention below – 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
– but not do so for ERLD.

One change to what you state below – I think “when a prefix is leaked or
redistributed, the ELC associated to the prefix MUST also be
leaked/redistributed.”.

   Les

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.

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 20 Nov 2018 06:52:19 +0000

Aijun –

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-masked]>
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
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

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]]
发送时间: 2018年11月20日 2:00
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, November 09, 2018 6:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Brgds,

Stephane

Thank you.

---

From: <[email-masked]>
Date: Tue, 20 Nov 2018 07:19:50 +0000

Hi all,

The use case is without TE. And this is how network designs are working today, and I do not see any valid reason to complexify and change the existing designs by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is quite simple.

Brgds,

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

Best regards,
Xiaohu

Stephane –

   Les

Hi WG,

Brgds,

Stephane

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 20 Nov 2018 16:09:51 +0800

Why not directly use the BGP over SR model just like the BGP over LDP model?

Best regards,
Xiaohu

------------------------------------------------------------------
From:stephane.litkowski <[email-masked]>
Send Time:2018年11月20日(星期二) 15:20
To:徐小虎(义先) <[email-masked]>; Lsr <[email-masked]>; [email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

Brgds,

From:徐小虎(义先) [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi all,

Best regards,
Xiaohu

Stephane –

   Les

Hi WG,

Brgds,

Stephane

---

From: <[email-masked]>
Date: Tue, 20 Nov 2018 08:25:09 +0000

We can’t for some internal design/security reasons.

From: Lsr [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Tuesday, November 20, 2018 09:10
To: spring; Lsr; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Best regards,
Xiaohu

Hi all,

Brgds,

Hi all,

Best regards,
Xiaohu

Stephane –

   Les

Hi WG,

Brgds,

Stephane

Thank you.

Thank you.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 20 Nov 2018 16:35:20 +0800

If I understood it correctly, draft-wang-lsr-ospf-prefix-originator-ext-00 is an OSPF counterpart of RFC7794 from the perspective of correlation of prefixes and their originator in the inter-area scenario. As such, these two drafts are useful for the usage of ELC in the inter-area scenario.

As for the inter-AS scenario, IMHO, BGP LSP over SR LSP is the best choice. In other words, I doubt the necessity of advertising the ELC across ASes VIA IGP REDISTRIBUTION.

Best regards,
Xiaohu
------------------------------------------------------------------
From:Les Ginsberg (ginsberg) <[email-masked]>
Send Time:2018年11月20日(星期二) 14:52
To:Aijun Wang <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Aijun –

Hope this is clear.

    Les

Best Regards.

Aijun Wang

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
发送时间: 2018年11月20日 2:00
收件人:  [email-masked]; lsr@ietf..org
抄送: [email-masked]
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Stephane –

   Les

---

From: <[email-masked]>
Date: Tue, 20 Nov 2018 10:00:51 +0000

As mentioned, you could not be aware of all the constraints that we have and BGP 3107 is not an option.
Note that this kind of redistribution can even happen within a single AS. We had some OSPF domain prefixes leaked in the ISIS L2 in the past in a single AS. Nothing prevents this design to come back again.

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Tuesday, November 20, 2018 09:35
To: spring; Aijun Wang; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Best regards,
Xiaohu

Aijun –

Hope this is clear.

    Les

Hi, Les and Stephane:

Best Regards.

Aijun Wang

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]]
发送时间: 2018年11月20日 2:00
收件人: [email-masked]<mailto:[email-masked]>; lsr@ietf..org<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

   Les

Hi WG,

Brgds,

Stephane

Thank you.

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 22 Nov 2018 09:18:46 +0800

Hi, Les:

Can we consider more aggressively to convert between the Router Information
LSA(defined in RFC7770) and  IS-IS Router CAPABILITY TLV(defined in RFC7981)
when we do OSPF/IS-IS redistribution?

When the redistribution occurs between different OSPF instances or IS-IS
instances, such LSA or TLV need only be flooded into another instances, no
conversion are involved.

Doing so can meet other future requirements for node capabilities
information between different IGP instances. And will not make the user
confusion for the usage of associated sub TLV.

Best Regards.

Aijun Wang

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
发送时间: 2018年11月20日 14:52
收件人: Aijun Wang; [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Aijun –

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.

Hope this is clear.

    Les

From: Aijun Wang <[email-masked]> 
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; stephane.litkowski@orange.
com; [email-masked]
Cc: [email-masked]
Subject: 答复: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi, Les and Stephane:

 

Best Regards.

Aijun Wang

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
发送时间: 2018年11月20日 2:00
收件人: [email-masked]; lsr@ietf..org <mailto:[email-masked]> 
抄送: [email-masked]
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

   Les

Hi WG,

 

Brgds,

Stephane