Re: [mpls] MT ID registry in draft-ietf-mpls-ldp-multi-topology
Alia Atlas <akatlas@gmail.com> Wed, 03 July 2013 18:35 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F111E81C5 for <mpls@ietfa.amsl.com>; Wed, 3 Jul 2013 11:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFI0n2QCkWS4 for <mpls@ietfa.amsl.com>; Wed, 3 Jul 2013 11:35:47 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF821F9D1E for <mpls@ietf.org>; Wed, 3 Jul 2013 11:35:46 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id x12so1189336ief.26 for <mpls@ietf.org>; Wed, 03 Jul 2013 11:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b1cAD9dI5UnGw4gX3wfgp0tyfHRKS+Qic9nEeUO2+as=; b=BbdyYXVk+m8dQB8A5uzYWJC0WGwJFbIB33RRhGH3M1tYy9xyHzpiiLSqxX4hfPF74/ 6jvVqZ/2e7KGUtARE5lAcVwq37/rUq2nBfoXeEotu+7bLZZr5pgA/rVWRyYzr8L10Ly3 S0yyEjCPlEIXHgtB1v9fRcGWDdCPlExty2+F0ozc93ez89S3r0GgFXTjor3VPopeoNqA XRnmivVplYbkeQ9mjt1mIWU3PsLT/NCTY303sNnUki1L3zwBipSljtK+FjDd9HSSv4iU BJFpqcdUCD/cOIQvfUjbKIByAgQ8GMMehDYhyyo7jNb4DGtDZcnIIgvDW8PBYTEO1nEC eUCg==
MIME-Version: 1.0
X-Received: by 10.43.0.67 with SMTP id nl3mr1298103icb.2.1372876545308; Wed, 03 Jul 2013 11:35:45 -0700 (PDT)
Received: by 10.64.47.168 with HTTP; Wed, 3 Jul 2013 11:35:45 -0700 (PDT)
In-Reply-To: <00a701ce7649$da9bd920$8fd38b60$@olddog.co.uk>
References: <00a701ce7649$da9bd920$8fd38b60$@olddog.co.uk>
Date: Wed, 03 Jul 2013 14:35:45 -0400
Message-ID: <CAG4d1re9pN1FybPd8BHgpiUgoCoLEUyFM=5SkqzvpH-u8jAs_w@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Content-Type: multipart/alternative; boundary="bcaec511e1b6cdbde204e09fbac0"
Cc: "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org, Quintin Zhao <quintin.zhao@huawei.com>
Subject: Re: [mpls] MT ID registry in draft-ietf-mpls-ldp-multi-topology
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 18:35:51 -0000
Hi Adrian, I think, in general, that automatic mapping is quite reasonable. This makes even more sense given that the LDP range is 16 bits long, the OSPF range is 7 bits long, and the IS-IS and PIM ones are 4096 bits long. I have heard of networks running both IS-IS and OSPF on overlapping routers - and LDP would take from both. I don't have the use-case to hand (this was a while ago) - but I don't think it is extremely uncommon. Just consider merger cases... (though that's not where I heard of it). Alia On Mon, Jul 1, 2013 at 6:57 AM, Adrian Farrel <adrian@olddog.co.uk> wrote: > Hi all,**** > > ** ** > > I want to try to bring the two threads on the MT ID ranges for IANA back > together to try to understand what is being proposed and what is possible. > **** > > ** ** > > First step is to recognise that the OSPF and ISIS registries exist and > already have numbers assigned from them. Thus we are not going to manage to > converge the OSPF and ISIS MT IDs into a single registry with the same > meanings.**** > > ** ** > > Alia says "it'd be very useful to have that range specifically set aside > for cases where it matters that it be the same" but doesn't give a concrete > example of such a case. **** > > ** ** > > Furthermore, I am not comfortable with the idea that both OSPF and ISIS > might be running at the same time, as is implied here, each distributing a > different default topology, but with the two topologies being aggregated > for use by LDP. Perhaps I don't see the network that you are trying to > build and deploy, and a picture will help explain it.**** > > ** ** > > My "understanding" of the use case is that a single instance of a single > IGP runs in an area. That IGP may distribute information about multiple > routing topologies, each topology having an MT ID. LDP is also running in > the area and distributes labels based on the preferred routes in each > topology. Thus each label advertisement includes a FEC and an MT ID.**** > > ** ** > > In order to use the labels correctly, there must be a mapping between the > MT IDs used by the IGP, and those used by LDP.**** > > ** ** > > It is also possible that through network-wide configuration of policy on > the LDP implementations, LDP will use the information from the IGP and the > configured policy to formulate new and different MPLS-only topologies. > Thus, LDP might use an MT ID for its own special topology.**** > > ** ** > > There are two options:**** > > ** ** > > 1. Create a registry that is agnostic to the IGP in use (i.e. doesn't > indicate OSPF or ISIS) and which shows the use of the topology.**** > > 0 Default topology**** > > 1 IPv4 in-band management topology**** > > 2 IPv6 routing topology**** > > 3 IPv4 multicast routing topology**** > > 4 IPv6 multicast routing topology**** > > 5 IPv6 in-band management topology**** > > 6 - a Reserved for future IGP topologies (standards action)**** > > a+1 - b Reserved for IGP experimental topologies**** > > b+1 - c Reserved for LDP topologies (standards action)**** > > c+1 - d Reserved for LDP experimental topologies**** > > ** ** > > 2. Create a registry that is aware of the IGP in use and is built on the > existing OSPF and ISIS registries.**** > > This would be modelled on what I suggested before, but adding allocations > for LDP itself...**** > > ** ** > > 0 Default/standard topology in IS-IS**** > > 1 IPv4 in-band management in IS-IS **** > > 2 IPv6 routing topology in IS-IS **** > > 3 IPv4 multicast topology in IS-IS **** > > 4 IPv6 multicast topology in IS-IS **** > > 5 IPv6 in-band management in IS-IS **** > > 6-3995 Unassigned (intended to mirror IS-IS)**** > > 3996-4095 Reserved for private use (from IS-IS) **** > > 4096 Default/standard topology in OSPF **** > > 4097 Default multicast topology in OSPF **** > > 4098 IPv4 in-band management in OSPF **** > > 4099-4127 Unassigned (intended to mirror OSPF)**** > > 4128-4255 Reserved for private use (from OSPF)**** > > 4256-4351 Reserved (IANA does not assign) **** > > 4352-4511 Unassigned**** > > 4512-4607 LDP use (standards action)**** > > 4608-65531 Reserved for Private Use**** > > 64432-65535 Experimental use**** > > ** ** > > ** ** > > In all cases, my concern is what happens when a new IGP use is defined in > an RFC. It would appear that the LDP registry has to be updated to keep it > in synch.**** > > It is also unclear to me how we handle mapping an IGP private use into the > LDP private use.**** > > The intention of the scheme in the second option is to make that mapping > automatic so that when an MT ID is used in an IGP, we know how to map to > the LDP MT ID even if we don't understand the meaning of the IGP's MT ID.* > *** > > ** ** > > It seems to me that what you might be asking for in your email is a single > MT ID value that is the default topology used by LDP when it is based on > OSPF or ISIS default topology and does not want to indicate which it comes > from. It that is the case, you could assign 4512 in option 2 for this > purpose.**** > > ** ** > > I am convinced that the solution to this problem is to work out what the > mapping algorithm is. How does an LDP implementation decide which MT ID to > use in a label advertisement? How does a packet-classifier decide which > label to use?**** > > ** ** > > The answer may be: "It is assumed that this mapping is manually configured > on every router"**** > > Or it may be: "There is an automatic mapping between IGP MT IDs and LDP MT > IDs"**** > > Or it may be something else.**** > > ** ** > > Once the answer is agreed, making a registry will be easy.**** > > ** ** > > Cheers,**** > > Adrian**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Quintin Zhao > *Sent:* 28 June 2013 21:41 > *To:* 'Alia Atlas' > *Cc:* mpls@ietf.org; draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org > *Subject:* Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology**** > > ** ** > > Hello Alia,**** > > ** ** > > Thanks for your review and suggestions.**** > > ** ** > > Indeed we need to allocate a MT ID range for the applications such as MRT > so that MT ID can be the same for OSPF, ISIS and LDP. **** > > ** ** > > We need decide how big this range should be for the applications such as > MRT. What is your recommendation for this range?**** > > ** ** > > This is what we have now from ISIS-MT(RFC5120):**** > > ** ** > > ** ** > > - MT ID #0: Equivalent to the "standard" topology.**** > > - MT ID #1: Reserved for IPv4 in-band management**** > > purposes.**** > > - MT ID #2: Reserved for IPv6 routing topology.**** > > - MT ID #3: Reserved for IPv4 multicast routing topology.**** > > - MT ID #4: Reserved for IPv6 multicast routing topology.**** > > - MT ID #5: Reserved for IPv6 in-band management**** > > purposes.**** > > - MT ID #6-#3995: Reserved for IETF consensus.**** > > - MT ID #3996-#4095: Reserved for development, experimental and**** > > proprietary features [RFC3692].*** > * > > ** ** > > This is what have now from OSPF-MT(RFC4915)**** > > ** ** > > 0 - Reserved for advertising the metric associated**** > > with the default topology (see Section 4.2)**** > > 1 - Reserved for advertising the metric associated**** > > with the default multicast topology**** > > 2 - Reserved for IPv4 in-band management purposes**** > > 3-31 - Reserved for assignments by IANA**** > > 32-127 - Reserved for development, experimental and**** > > proprietary features [RFC3692]**** > > 128-255 - Invalid and SHOULD be ignored**** > > ** ** > > The range which is available for us to use is from 6 -127.**** > > ** ** > > Thanks,**** > > Quintin**** > > ** ** > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* 2013年5月29日 8:52 > *To:* Adrian Farrel > *Cc:* draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org; mpls@ietf.org > *Subject:* Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology**** > > ** ** > > Hi Adrian & authors,**** > > ** ** > > I have a couple comments on the IANA registry and number overlapping.**** > > ** ** > > First, it would be useful to have a range that is clearly intended to be > the same for OSPF, ISIS and LDP. Given the**** > > extremely limited range for OSPF multi-topology routing ( > http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of*** > * > > 3-127, it'd be very useful to have that range specifically set aside for > cases where it matters that it be the same. **** > > ** ** > > One use that I see for this draft is for MRT, which is doing > multi-topology forwarding but not multi-topology routing. This means**** > > that the MT-IDs used do not need to overlap with those in OSPF or ISIS. > It would be good to ensure that there's a reasonable**** > > range in LDP for such purposes. LDP is one of the few mechanisms that > easily lends itself to multi-topology forwarding.**** > > ** ** > > Alia**** > > ** ** > > P.S. Having the same values for mLDP and PIM may also be very useful for > interworking. PIM doesn't actually have an IANA**** > > registry for MT-ID and leaves the meaning of the values up to the network > operator.**** > > ** ** > > On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel <adrian@olddog.co.uk> > wrote:**** > > Hi authors, > > Thanks for this document. > > I have done my usual AD review which is intended to catch any issues > that I see, and to smooth out the wrinkles before the I-D goes to IETF > last call and IESG review. > > As you will see below, I have a number of editorial comments (nits and > larger changes) and also a few questions/issues. > > The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. > I suggest you read the comments against those sections all together. > Note that in my comment for section 9, I think I have worked out what > you need to do, and so the resolution to the comments for 3.4 and 3.8 > may simply be documenting this change to the IANA registry. > > As usual, all my comments are up for discussion, so please don't feel > you are required to make changes if you think there is a good reason why > things are the way they are. > > At the moment it looks like a new revision will be needed to address the > review, so I have set the flag in the datatracker. Please work with your > document shepherd to produce and post a new revision. > > Thanks, > Adrian > > === > > The document seems to end with a spurious page header. > > --- > > The index seems to be considerably adrift from reality. > In particular, there is no Appendix in this document. > > --- > > Why do you say that this updates RFC 4379? Is it your belief that an > implementation of RFC 4379 will not be complete/conformant without these > extensions? Or are you just defining extensions which an implementation > in an MPLS-MT environment will need to support? > > I note that you (in my view, correctly) do not say that this document > updates RFC 5036, yet it defines extensions to LDP in a similar way. > > --- > > Please expand all acronyms on first use unless they show with an > asterisk in the RFC Editor's list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I see: > CSP > LSP > QoS > > --- > > Abstract and Introduction > > "IGP protocol" is bad because the "P" in "IGP" is "protocol". > > --- > > The RFC Editor prefers documents to have the Introduction as Section 1. > > You may prefer to make this change yourself, because it will possibly > cause some expansions of terms and acronyms that the RFC Editor might > so in a way you don't like. > > --- > > In section 1, the term "MT Topology" is odd because the "T" of "MT" > stands for "Topology". Surely you don't mean "Multi Topology Topology"? > > --- > > Section 3.1 > > s/infers/implies/ > > --- > > Section 3.2 > > I prefer that you don't repeat protocol encodings that are defined > elsewhere. This can cause nasty problems if you make a mistake or if > the original definition is updated. > > It is enough for you to write... > > The LDP base specification [RFC5036] (Section 4.1) defines the > "Prefix" FEC Element. The "Prefix" encoding is defined for a given > "Address Family" (AF), and has length (in bits) specified by the > "PreLen" field. > > To extend IP address families for MT, two new Address Families named > "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes > within a topology scope. > > --- > > Section 3.2 Figure 2 > > This figure gives the impression that both IPv4 and IPv6 addresses are > four bytes long! > > I think you need: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IP Address ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | MT-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: MT IP Address Family Format > > ...and... > > Where "IP Address" is a variable length field padded to a four octet > boundary and containing an IPv4 or IPv6 address/prefix for the "MT > IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to > the 16-bit Topology ID for given address. > > ...but you need to check I got that right! > > However, before doing this work, see my comment on Section 3.3 > > --- > > Section 3.2 > > The proposed FEC Elements with "MT IP" Address Family can be used in > > You are not proposing any more, you are defining! > > See also section 3.6, 3.8, 4.1, 4.3, and 8 > > --- > > Section 3.2 > > [RFC5036] does not specify the handling of "Unknown" Address > Families. Therefore, [RFC5036] will need to be updated to include > the handling procedure for unknown address families. > > Ouch! > > This had me really worried because it implied that you are breaking > existing LDP deployments. But I discussed it with Loa, and he pointed me > at Section 3.4.1.1 of RFC 5036 > > "If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address Family it does not support, it SHOULD stop decoding the FEC > TLV, abort processing the message containing the TLV, and send an > "Unsupported Address Family" Notification message to its LDP peer > signaling an error. > > If it encounters a FEC Element type it cannot decode, it SHOULD stop > decoding the FEC TLV, abort processing the message containing the > TLV, and send an "Unknown FEC" Notification message to its LDP peer > signaling an error." > > So I think you can just delete this paragraph. > > Furthermore, Section 3.5 defines a capability advertisement that enables > you to know whether it is safe to use one of the new AFs. So surely you > should also say "MUST NOT send an MT AF unless the peer has said it can > handle it." > > See my re-write in the next comment. > > --- > > Section 3.3 appears to be repeating a lot of Section 3.2, but in a > better and more concise way. For example, Figure 3 nicely shows how the > Prefix FEC element works with the new AFs. > > This leads me to think that Section 3.2 could be reduced to just a few > lines that say... > > The LDP base specification [RFC5036] (Section 4.1) defines the > the use of an "Address Family" (AF) field in FEC Elements to indicate > the encoding of the "Prefix" or "Address" that follows, and to > indicate how the FEC should be interpreted. > > This document defines two new AF values named "MT IP" and "MT IPv6" > that are used to specify the use of IPv4 or IPv6 within a topology > scope. The data associated with these new AFs includes an "MT-ID" > field that carries the 16-bit Topology ID for a topology. > > The value of MT-ID=0 corresponds to default topology and MUST be > ignored on receipt so as to not cause any conflict/confusion with > existing non-MT procedures. > > FEC Elements with the new AFs can be used in any LDP message and > procedures that currently specify and allow the use of FEC Elements > with the IP or IPv6 AFs, but MUST NOT be used unless the peer has > indicated it can handle them as described in Section 3.5. Note that > behavior by an LDP speaker that receives a FEC element containing an > unknown AF is described in Section 3.4.1.1 of [RFC5036]. > > --- > > Section 3.4 is perfectly clear except it doesn't say what "reserved", > "special", and "translating" mean. > > This opens up a number of questions including why you need a registry > at all. Presumably the "translation" needed is to ensure that the > values used in LDP have the same meaning as they do in the IGP. If that > is the case, why not simply use exactly the same value? > > And looking at the registry further, it seems to say that only values > allocated by IANA and stored in the registry can be used. That means > that an operator that wants to use MT in their network cannot just > assign values to the MT-IDs for the topologies because the registry > has no space for this to happen. > > Now, it is possible that you have simply used the wrong words in the > registry in section 9, and failed to provide any explanation in the > text. Note that "unassigned" means "not yet assigned, but available > to be assigned by IANA". And "Reserved" means "Do not assign until > a new RFC defines how they should be used." > > But there are other questions: > > Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? > I guess 16 is convenient to hold either, but how are the top 4 bits to > be handled? > > How do you handle the case where there are multiple instances of an IGP > (or different IGPs) running? > > If you *do* expect there to be a mapping function between IGP MT-ID and > LDP MT-ID, how do you ensure the same function is used at both ends of > an LDP session? > > But Section 3.8 really does seem to say that only MT-IDs in the registry > are allowed, which seems to make this I-D almost useless because you > have only defined "default" (which we have already), "ISIS IPv6", and > "all". Isn't an operator allowed to partition their network into > topologies? > > So... > > I think what you need in Section 9 is... > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. The allocation policies for this registry > are: > > Range Registration Policy > ------ ------------------- > 0-3995 Expert Review > 3996-4095 Private Use > 4096-4127 Expert Review > 4128-4255 Private Use > 4256-4351 Reserved (IANA does not assign) > 4352-4511 Expert Review > 4512-65535 Private Use > > IANA is requested to populate this registry as follows: > > > Range/Value Purpose Reference > ----------- ------------------------------------- --------- > 0 Default/standard topology in IS-IS [This.I-D] > 1 IPv4 in-band management in IS-IS [This.I-D] > 2 IPv6 routing topology in IS-IS [This.I-D] > 3 IPv4 multicast topology in IS-IS [This.I-D] > 4 IPv6 multicast topology in IS-IS [This.I-D] > 5 IPv6 in-band management in IS-IS [This.I-D] > 6-3995 Unassigned (intended to mirror IS-IS) > 3996-4095 Reserved for private use (from IS-IS) [This.I-D] > 4096 Default/standard topology in OSPF [This.I-D] > 4097 Default multicast topology in OSPF [This.I-D] > 4098 IPv4 in-band management in OSPF [This.I-D] > 4099-4127 Unassigned (intended to mirror OSPF) > 4128-4255 Reserved for private use (from OSPF) [This.I-D] > 4256-4351 Reserved (IANA does not assign) [This.I-D] > 4352-4511 Unassigned > 4512-65535 Reserved for Private Use [This.I-D] > > This would address many of the issues in Sections 3.4 and 3.8, and needs > to be discussed in those sections. > > --- > > In Section 3.5 > > o Length: The length (in octets) of TLV. > > Are you sure it is not just the length in octets of the value? > Compare with RFC 5036 Section 3.3 > > --- > > Sections 3.5 and 3.6 need to be more closely grouped. > > Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 > > --- > > Section 3.6 > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker MAY send an "MT Capability" > including the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker MAY send "MT Capability" with one or more MT Typed FEC > elements in it. > > I don't think this is "MAY" in either case. This *is* how the LDP > speaker announces it. There is no other way to announce it. So... > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker sends an "MT Capability" including > the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker sends "MT Capability" with one or more MT Typed FEC elements > in it. > > --- > > Section 3.6 > > o If an LSR has not advertised MT capability, its peer must not send > messages that include MT identifier to this LSR. > > Isn't that "MUST NOT"? > > --- > > Section 3.8 > > Certain MT topologies are assigned to serve predetermined purposes: > > It is not the topology that is assigned, but the MT-ID. Should read: > > Certain MT-ID values are assigned to indicate specific meanings: > > --- > > Section 3.8 > > It is not helpful to "propose" numbers in this section and then to > also reference Section 9 for the definitive numbers. I suggest you > remove all numbers from this section and simply point at Section 9. > > --- > > Section 4.2 > > This MAY allow an LDP speaker to signal its IP convergence... > > What does 2119 MAY mean in this context? > > --- > > Section 4.3 > > [RFC4379] defines procedures to detect data-plane failures in MPLS > LSPs via LSP ping. The specification defines a "Target FEC Stack" > TLV that describes the FEC stack being tested. > > Ha, ha! You got me :-) > s/The specification/That specification/ > > --- > > Section 4.3.1 > > Sub-Type Length Value Field > -------- ------ ----------------- > TBA5 5 MT LDP IPv4 prefix > TBA6 17 MT LDP IPv6 prefix > > Are you sure you don't mean 8 and 20? > > --- > > Section 4.3.4 > > When detect data plane failures using LSP Ping for a specific topoly, > the router will intiate an LSP Ping request with the targer FEC stack > > I think > > s/When/To/ > > s/topoly/topology/ > > s/intiate/initiate/ > > s/targer/target/ > > --- > > Section 4.3.4 > > For the case that the LSP ping with return path not specified , the > reply packet may go through the default topology instead of the > topology where the Echo Request goes through. > > Is that really "the default" or "any"? > If you mean "the default" then I think you need some "MUST NOT" text to > talk about other topologies. > > --- > > Section 5 > > The extensions defined in this document utilise the existing LDP > error handling defined in [RFC5036]. If an LSR receives an error > notification from a peer for an MPLS-MT session, it terminates the > LDP session by closing the TCP transport connection for the session > and discarding all MT-ID label mappings learned via the session. > > There is nothing wrong with this text, but it does open a question that > is not addressed anywhere in the document: what is the relationship > between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? > > This is somewhat assumable from the discussion of multiple MT-ID > wildcard FEC elements in the Multi-Topology Capability TLV, but it is > not explicit. > > --- > > Shouldn't Section 6 comment on how each of the new protocol elements > will not be seen by a legacy implementation because they are only used > after successful capability negotiation? > > But you do need to describe how a legacy node will react to attempted > MT capability negotiation. > > You could also restate the reference to RFC 5036 section 3.4.1.1 since > this issue seemed to be a question for you. > > --- > > I'm slightly doubtful about the value of Section 7, but I note that the > point you are trying to convey is not quite worded correctly. You have: > > and the specified > signaling mechanisms do not provide any way for the data plane to > associate a given packet with a context-specific label space. > > I don't think the signaling mechanism is relevant, and I think "context- > specific" hides what you are trying to say. Perhaps you should have: > > and there is no way > for the data plane to associate a received packet with any one > topology, meaning that topology-specific label spaces cannot be used. > > --- > > Section 9 > > o New Status Code: "Multi-Topology Capability not supported" > (requested code point: TBA2 from LDP registry "Status Code Name > Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is an implementation that does not know the new MT Capability > TLV supposed to generate this status code? Or are you referencing an > existing error code: in which case it should not appear in this section. > > o New Status Code: "Unknown Address Family" (requested code point: > TBA4 from LDP registry "Status Code Name Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is a legacy implementation that does not know either of your > new MT AFs supposed to generate this status code? But I suspect you are > just referencing an existing error code (see Section 3.2) as defined in > RFC 5036, and so you should not mention it in this section. > > Figure 10 does not show either of these status codes. > > --- > > Figure 10 shows a specific value for the new status code. Is this a > request or demand? I don't think it has already been allocated. > > --- > > Section 9 > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. > > This registry is discussed earlier in my notes. but please be aware that > you will need to define the allocation policy because it is a new > registry. > > --- > > Section 9 > > I want to ask Loa Andersson to look again at the LSP Ping TLV > allocations to check that they conform to the work he is currently > doing with that registry. > > --- > > It would help considerably to add a Manageability Considerations section > to this document because the function being added here is not simple to > manage or operate, and will have impact on the way that the network is > run. Good guidance on such sections can be found in RFC 5706. Appendix A > is particularly helpful at summarising things to consider. > > -------------------- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** >
- [mpls] MT ID registry in draft-ietf-mpls-ldp-mult… Adrian Farrel
- Re: [mpls] MT ID registry in draft-ietf-mpls-ldp-… Alia Atlas