[mpls] MT ID registry in draft-ietf-mpls-ldp-multi-topology

["Adrian Farrel" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Quintin
Zhao
Sent: 28 June 2013 21:41
To: 'Alia Atlas'
Cc: [e-mail]; [e-mail]
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:[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