Subject: Re: [mpls] I-D Action: draft-andersson-mpls-open-dt-questions-00.txt

From: Toerless Eckert <[email-masked]>
Date: Wed, 12 May 2021 04:47:15 +0200

Any reason why we still need to bother with LDP for future "extended" MPLS
networks ? Not that we do not want to maintain it where it exists, but
in the context of the extensions we are discussing, i am not aware of any
signaling requirement where current IETF mindset would not prefer IGP over
LDP (and for IMHO good reasons). SR uses AFAIK IGP both for network wide and
only-to-subnet-neighbor information dissamination.

Cheers
    Toerless

On Thu, Apr 29, 2021 at 02:55:11PM +0100, Stewart Bryant wrote:
> Hi Loa
> 
> LDP really layers on an IGP in most practical networks and the IGP can flood this without missing a heartbeat.
> 
> - Stewart
> 
> 
> > On 29 Apr 2021, at 14:41, Loa Andersson <[email-masked]> wrote:
> > 
> > Stewart,
> > 
> > I was that concerned about the amount of data that needs to be flooded, but rather that the mechanisms we have is insufficient.
> > 
> > In the LDP case an LSR informs its peers about capabilities, they are not flooded across the network
> > 
> > RFC 5561
> > 
> >   - Each LDP speaker is assumed to implement a set of enhancements,
> >     each of which has an associated capability.  At any time, a speaker
> >     may have none, one, or more of those enhancements "enabled".  When
> >     an enhancement is enabled, the speaker advertises the associated
> >     capability to its peers.  By advertising the capability to a peer,
> >     the speaker asserts that it shall perform the protocol actions
> >     specified for the associated enhancement.  For example, the actions
> >     may require the LDP speaker to receive and process enhancement-
> >     specific messages from its peer.  Unless the capability has been
> >     advertised, the speaker will not perform protocol actions specified
> >     for the corresponding enhancement.
> > 
> > An LSR that initiates an LSP with a maximum scanning depth depth need to know this for every LSR along the LSP.
> > 
> > /Loa
> > 
> > On 29/04/2021 12:25, Stewart Bryant wrote:
> >> It is one additional capability field (no more than a byte) to flood and I find it hard to imagine that it would not scale.
> > 
> > -- 
> > 
> > Loa Andersson                        email: [email-masked]
> > Senior MPLS Expert                          [email-masked]
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 May 2021 11:17:10 +0100

We really need to support networks that are deployed with LDP.

Maybe one of the SPRING experts on the list can tell me whether the LS approach to label distribution scales to the levels that we need to support LS and a full replacement to LDP?

I would think that it should be able to, but the SR migration to LS for label distribution led to a few surprises and would like to be sure that all elephants have been accounted for.

- Stewart

> On 12 May 2021, at 03:47, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 May 2021 14:19:14 +0200

> We really need to support networks that are deployed with LDP.

Sure, but do we think any signaling extensions for the functions we are interested
in should be added to LDP or rather IGP ? E.g.: AFAIK (and i may be wrong),
all MPLS networks using LDP also use IGP, so we definitely would have the choice.

> Maybe one of the SPRING experts on the list can tell me whether the LS approach to label distribution scales to the levels that we need to support LS and a full replacement to LDP?

Indeed. The way i understand it, SR can use IGP more efficiently than LS
could because you can flood SR (and only deal with SR<->Label mapping on a per-hop
basis without doing it per SID/per-label). What LDP does would more naturally map
to a DV IGP than our typical MPLS LS IGPs.

> I would think that it should be able to, but the SR migration to LS for label distribution led to a few surprises and would like to be sure that all elephants have been accounted for.

I think you are quite right, but i was thinking that any additional signaling we would
need for the additional forwarding plane functions we come up with would be tied to
FEC and not label, and that AFAIK would again allow to easily flood it via LS IGPs.
And keep FEC to label mapping in LDP.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 13 May 2021 20:31:14 -0700

Loa,

RFC8491/RFC8476/RFC8814 provide IGP/BGP-LS framework to signal HW capabilities wrt abilities to push/read label stacks.

Please use common terminology - read instead of scan.
ERLD(Entropy Readable Label Depth)-MSD  is defined in draft-ietf-isis-mpls-elc and should be used to advertise readable label stack depth.

Cheers,
Jeff
On Apr 29, 2021, 3:26 AM -0700, Stewart Bryant <[email-masked]>, wrote:
>
>
> 2.1.3. Does flooding om maximum scanning depth of an LSR scale?
>
> A remedy for the issues in Section 2.1.1 has been suggested, the
> maaximum scanning depth for each LSR in the network should be flooded
> to all othr LSRs and used as a constraint when setting up LSPs.
>
> Would that scale satisfactorily.
>
> Hi Loa
>
> That is a duplicate of 2.1.2 and I think we can answer that as yes.
>
> Best regards
> > On 29 Apr 2021, at 08:59, [email-masked] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> > Title : MPLS Open Design Team Questions
> > Author : Loa Andersson
> > Filename : draft-andersson-mpls-open-dt-questions-00.txt
> > Pages : 4
> > Date : 2021-04-29
> >
> > Abstract:
> > This document is a living document, meaning that during the life
> > timme of the MPLS Open Design Team we will put additonal questions/
> > issues into the document. When we find an answer amd a way to
> > document the issu it will be removed from this document.
> >
> > Ideally when the Design Team is closed this document will be empty,
> > or maybe we just add a pointer to where the answer to quesstion is
> > documented. Thus this document will never go on to become an RFCc.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-andersson-mpls-open-dt-questions/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-andersson-mpls-open-dt-questions-00
> > https://datatracker.ietf.org/doc/html/draft-andersson-mpls-open-dt-questions-00
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Sergey Fomin" <[email-masked]>
Date: Mon, 17 May 2021 10:00:06 -0700

Hi Jeff,

> ERLD(Entropy Readable Label Depth)-MSD  is defined in draft-ietf-isis-mpls-elc and should be used to advertise readable label stack depth.

Not in a general case though.

As you may remember, there were quite a few discussions around the definition of RLD/ERLD for rfc8662 & drafts isis/ospf-mpls-elc, and the (rough) consensus settled on a strict, application specific definition & usage of ERLD, not a generic RLD.

--

Sergey

From: mpls <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Thursday, May 13, 2021 8:31 PM
To: mpls <[email-masked]>; loa Andersson <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: Re: [mpls] I-D Action: draft-andersson-mpls-open-dt-questions-00.txt

Loa,

 

Cheers, 

Jeff

On Apr 29, 2021, 3:26 AM -0700, Stewart Bryant <[email-masked] <mailto:[email-masked]> >, wrote:

Hi Loa

Best regards

- Stewart

On 29 Apr 2021, at 08:59, [email-masked] <mailto:[email-masked]>  wrote:

Abstract:

[email-masked] <mailto:[email-masked]> 

_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls