Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology

[Alia Atlas <[e-mail]>]

Hi Quintin,

I think it is useful to have a range of MT-IDs which is the same for OSPF,
IS-IS, and LDP.  I do not personally know of a specific use where this is
required.  Given that the OSPF range is only 7 bits long, I'd suggest no
more than 16 for this purpose - and reserve another 32 just in case.

For MRT, the only protocol in which the MT-IDs are actually signaled is LDP
(and possibly PIM).  Both of those have a range of 4096 for the signaling.
  I think it would be useful to have many of these available (up to 16
even) - but that's to more easily support different MRT Profiles for
different purposes on the same network at the same time.

Alia


On Fri, Jun 28, 2013 at 4:40 PM, Quintin Zhao <[e-mail]>wrote:

> 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:[e-mail]]
> *Sent:* 2013年5月29日 8:52
> *To:* Adrian Farrel
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>