Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01

From: Lizhong Jin <[email-masked]>
Date: Fri, 18 Nov 2011 23:24:47 +0800

Hi,
I agree with Ice's summary. I don't think it is very difficult to choose
the option of signaling MT-ID within FEC.

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 17 Nov 2011 23:34:50 +0800
> From: IJsbrand Wijnands <[email-masked]>
> To: Quintin Zhao <[email-masked]>
> Cc: [email-masked]
> Subject: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Quintin,
>
> During the MPLS WG presentation you asked for feedback on the different
> options to signal the MT-ID. See below;
>
> I've worked on this with Kamran Raza and we came to the conclusion there
> is really only one good option to signal the MT-ID, and that is within the
> FEC. This is true for LDP, and very much true for mLDP. We documented the
> preferred solution for mLDP, which would also apply to LDP. See;
>
> draft-iwijnand-mpls-mldp-multi-topology-00.txt
>
> Below is a summary of the reasons;
>
> - The LDP spec allows for multiple FEC's to be signaled in a single label
> mapping. If you don't add the MT-ID into the FEC its becomes difficult to
> match the MT-ID the right FEC, so you can't mix and match FEC elements, for
> example for IPv4 and IPv6. For the same reason Address Family is part of
> the FEC.
>
> - The MT-ID is something that is directly related to the Prefix/Root
> address encoded in the FEC, so it makes sense to combine them.
>
> - LDP messages and specifications that use FEC (e.g. Typed Wildcard,
> End-of-LIB) will automatically be extended for MT. There is no need to
> specify for which messages (map, withdraw, release etc..) the MT-ID applies.
>
> - If you are doing mLDP Live-Live using MTR (or MRT) and the 2 LSPs
> merge/overlap for some reason, you potentially duplicate the traffic and
> prevent live-live from working. For that reason the MT-ID MUST be in the
> FEC to make sure the 2 LSPs are unique and will never accidentally merge.
>
> - With mLDP a router may receive label mappings from multiple downstream
> routers, each of them including a different MT-ID. At that point you would
> need come up with some selection logic on which MT-ID you need to select
> and signal upstream. If the MT-ID is part of the FEC, you don't have that
> problem.
>
>
> Thx,
>
> Ice & Kamran
>
>
> ------------------------------
>
> _______________________________________________

---

From: Eric Rosen <[email-masked]>
Date: Mon, 21 Nov 2011 11:54:34 -0500

I also prefer the encoding where the MT-ID is encoded as part of each FEC
element.  In LDP, a Label Mapping Message creates a mapping from each of the
included FEC elements to a label.  In a single topology, the FEC element is
an address prefix, and the mapping is from a prefix to a label.  In a
multitopology network, the mapping is not from a prefix to a label, it's
from a <prefix, MT-ID> ordered pair to a label.  So if we want to maintain
the idea that LDP sets up mappings from FEC elements to label, we have to
treat the <prefix, MT-ID> ordered pair as a FEC element.

In general, extensions to LDP have retained the concept that one should be
able to map from FEC element to label, and we should try not to depart from
that paradigm.  Many LDP features are specified in terms of FEC elements,
and most of the LDP specs (and implementations) assume that you can look up
a FEC element to find the corresponding LSP.

The only argument I've heard in favor of the other options is the following:

    An LDP message may contain multiple FEC elements.  But there is no need
    to have a single LDP message that contains FEC elements from different
    topologies.  Therefore the most efficient way of encoding the message is
    to include the MTid just once per message, in its own TLV.  This is a
    much more efficient encoding than you get by repeating the MT-ID in
    every FEC element.

This argument does point out a disadvantage of this option; it isn't the
option that results in the shortest messages.  But I don't think this factor
outweighs the advantages of maintaining the ability to map from a FEC
element to a label.  Maintaining the proper semantics is more important than
shortening the message size.

(One could also argue that there may well be cases where it is convenient to
assign the same label to prefixes from different topologies; think of cases
where the label assigned is explicit null.)

---

From: Alia Atlas <[email-masked]>
Date: Mon, 21 Nov 2011 12:11:05 -0500

I am also strongly in favor of having the MT-ID encoded as part of
each FEC element.  The idea of specifying address families that
include MT-ID seems a particularly functional way of doing so.

I also have a case where it makes perfect sense to include multiple
FEC/Label bindings in a single message where each FEC refers to a
different MT-ID.  This is for MRT fast-reroute, where one may want to
send a FEC for the loopback address with the default topology as well
as FECs for the loopback address on the blue MRT topology and on the
red MRT topology.

Alia

On Mon, Nov 21, 2011 at 11:54 AM, Eric Rosen <[email-masked]> wrote:
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Quintin Zhao <[email-masked]>
Date: Tue, 22 Nov 2011 02:07:46 +0800

Hello Eric, Ice, Alia, Lizhong,

Thanks for your detailed reasoning points on why we should chose the option3, which puts MPLS-MT ID inside FEC element, of the three choices we have presented last Monday in the IETF meeting，http://www.ietf.org/proceedings/82/slides/mpls-3.ppt）.

After Monday's presentation, we had discussions among co-authors and we also had the consensus that option3 is a more flexible and scalable choice.

I agree with Eric’s point that one of the main reason for choosing option3 is that maintaining the proper semantics is more important than shortening the message size.

For Alia's point using multiple FEC elements with different MT-ID for the protections, it is a very good idea! We have the similar scenario for mLDP’s protections (see the page6-9 of the presentation we gave on RTG’s meeting last week, http://www.ietf.org/proceedings/82/slides/rtgwg-6.ppt ). 

Regarding to Ice's email, I'd like to get a clarification for the following in your reasoning points：
(1) For first reasoning point, what is the scenario where IPv4 FEC element and IPv6 FEC element are mixed together in a message to share a same label TLV?
(2) For the fourth reasoning point, when do we have the accident merge here using MRT or MTR? If the two messages are for different topologies, why do you merge them?
(3) For the 5th reasoning point, why do we need to merge the label mappings if these labels map to address belong to different topology? Label aggregation?
 
We have updated LDP MT extension draft (draft-ietf-mpls-ldp-multi-topology-02.txt) to reflect this choice of encoding the MPLS-MT ID inside the FEC element.
 
Again, thanks for your time and your comments and suggestions have made our draft a better document.

Quintin

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 21 Nov 2011 19:28:27 +0100

Quintin,

> After Monday's presentation, we had discussions among co-authors and we also had the consensus that option3 is a more flexible and scalable choice.

Great.

> (1) For first reasoning point, what is the scenario where IPv4 FEC element and IPv6 FEC element are mixed together in a message to share a same label TLV?

It is an example, if rfc5036 allows for it, you don't want to break it just because of MT-ID, right?

> (2) For the fourth reasoning point, when do we have the accident merge here using MRT or MTR? If the two messages are for different topologies, why do you merge them?

It is not about the messages, it is about the mLDP state. MRT or MTR may have a router that is shared between 2 topologies (maybe accidental or just because there is no dual topology).

> (3) For the 5th reasoning point, why do we need to merge the label mappings if these labels map to address belong to different topology? Label aggregation?

These are label mappings from 2 different downstream routers.

Thx,

Ice.

---

From: Kamran Raza <[email-masked]>
Date: Mon, 21 Nov 2011 13:53:38 -0500

> what is the scenario where IPv4 FEC element and IPv6 FEC element are mixed
> together in a message to share a same label TLV?
One such example is the advertisement/withdrawal/change of a null label
(implicit null or explicit null) associated with one/more prefixes
potentially across different IP Address families. -- e.g. an LSR can
advertise/withdraw implicit-null label for a (mixed) set of IPv4 and IPv6
prefixes and hence have a single FEC TLV with mixed (IPv4 and IPv6) Prefix
FEC elements associated with a single label specified in single Label TLV in
a given Label Mapping msg.

Rgds, -- Kamran
_______________________________________________ mpls
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mpls

-- 
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 21 Nov 2011 20:01:52 -0600

Same here, much prefer MT-ID is encoded as part of each FEC element, treat the <prefix, MT-ID> ordered pair as a FEC element. This way we maintain the consistent semantics in handling the LDP set up mappings from FEC elements to label, as Eric described. Thanks to Eric for the clear reasoning, and Alia for the MRT FRR use case.

Discussed with Ice and Quintin separately last week in Taipei on using FEC as the preferred encoding option as well, we were very much in synch on this.

Thanks,
Luyuan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: Monday, November 21, 2011 12:11 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Lizhong Jin
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01
>

---

From: "Chao Zhou (czhou)" <[email-masked]>
Date: Mon, 21 Nov 2011 21:10:17 -0600

Quintin has submitted a new version based on our discussion and feedback from various sources. Please review the new version and if possible, move to the next step.

Thanks.
-Chao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luyuan Fang (lufang)
Sent: Tuesday, November 22, 2011 10:02 AM
To: Alia Atlas; [email-masked]
Cc: [email-masked]; [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01

Thanks,
Luyuan