Subject: Fwd: AD-review comments on MSDP

From: Alex Zinin <[email-masked]>
Date: Mon, 10 Feb 2003 07:44:53 -0500

I didn't receive comments from anyone on the directorate :(
FYI my comments below.

-- 
Alex

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: David Meyer <[email-masked]>, Bill Fenner <[email-masked]>
Cc: [email-masked]
Date: Friday, February 7, 2003, 9:43:13 AM
Subject: AD-review comments on MSDP

===8<==============Original message text===============
Dave, Bill-

Below are my comments on the MSDP spec.

Since you haven't replied to my earlier e-mails
about mesh-groups and FSM, I'm including those
questions here.

>                Multicast Source Discovery Protocol (MSDP)
>                      <draft-ietf-msdp-spec-14.txt>
> 
> 
> 
> 1. Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC 2026.
> 
>    Internet Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
> 
> 2. Abstract

Ed: Remove numbering from Status and Abstract

>    The Multicast Source Discovery Protocol, MSDP, describes a mechanism
>    to connect multiple PIM-SM domains together. Each PIM-SM domain uses
>    its own independent RP(s) and does not have to depend on RPs in other
>    domains. This draft is intended to document existing MSDP
>    implementations in the field.

Ed: Expand "RP" in the abstract

...

> 6. Procedure
> 
>    When an RP in a PIM-SM domain first learns of a new sender, e.g. via
>    PIM register messages, it constructs a "Source-Active" (SA) message
>    and sends it to its MSDP peers. The SA message contains the following
>    fields:

Spell out that RPs always need to be MSDP speakers?

...

> 13.3. MSDP mesh-group semantics
> 
>    An MSDP mesh-group is a operational mechanism for reducing SA
>    flooding, typically in an intra-domain setting. In particular, when
>    some subset of a domain's MSDP speakers are fully meshed, they can be
>    configured into a mesh-group.
> 
>    Note that mesh-groups assume that a member doesn't have to forward an
>    SA to other members of the mesh-group because the originator will
>    forward to all members. To be able for the originator to forward to
>    all members (and to have each member also be a potential originator),
>    the mesh-group must be a full mesh of MSDP peering among all members.
> 
>    The semantics of the mesh-group are as follows:
> 
>    (i).    If a member R of a mesh-group M receives a SA message from an
>            MSDP peer that is also a member of mesh-group M, R accepts the
>            SA message and forwards it to all of its peers that are not
>            part of any mesh-group.

did you mean "any" or mesh-group M?
following the text, if R receives an SA from X within mesh group M1,
it won't forward it along to Y which may be in M2. If X doesn't have
a session in M2, the message won't get flooded.

>  R MUST NOT forward the SA message to
>            other members of mesh-group M.
> 
>    (ii).   If a member R of a mesh-group M receives a SA message from an
>            MSDP peer that is not a member of mesh-group M, and the SA
>            message passes the peer-RPF check, then R forwards the SA
>            message to all members of mesh-group M.

Why only within M? what about other peers?

> 
> 14.  MSDP Connection State Machine
> 
>    MSDP uses TCP as its transport protocol. In a peering relationship,
>    one MSDP peer listens for new TCP connections on the well-known port
>    639. The other side makes an active connect to this port. The peer
>    with the higher IP address will listen. This connection establishment
>    algorithm avoids call collision. Therefore, there is no need for a
>    call collision procedure. It should be noted, however, that the
>    disadvantage of this approach is that the startup time depends
>    completely upon the active side and its connect retry timer; the
>    passive side cannot cause the connection to be established.
> 
>    An MSDP peer starts in the DISABLED state. MSDP peers establish
>    peering sessions according to the following state machine:
> 
> 
> 
> 
> 
> 
>                   --------------->+----------+
>                  /                | DISABLED |<----------
>                 |          ------>+----------+           \
>                 |         /            |E1->A1            |
>                 |        |             |                  |
>                 |        |             V                  |E7->A7
>                 |        |        +----------+ E3->A3 +--------+
>                 |        |        | INACTIVE |------->| LISTEN |
X>                 |        |        +----------+        +--------+
>                 |        |     E2->A2|    ^               |E5->A5
>                 |        |           |    |               |
>                 |        |E7->A6     V    |E6             |
>                 |         \      +------------+           |
>                 |          ------| CONNECTING |           |
>                 |                +------------+           |
>        E7->A8   |                      |E4->A4            |
>        E8->A8   |                      |                  |
>        E9->A8   |                      V                  |
>                  \              +-------------+          /
>                   --------------| ESTABLISHED |<---------
>                                 +-------------+
>                                    |       ^
>                                    |       |
>                              E10->A9\______/
> 14.1. Events
> 
> 
>        E1) Enable MSDP peering with P
>        E2) Own IP address < P's IP address
>        E3) Own IP address > P's IP address
>        E4) TCP established (active side)
>        E5) TCP established (passive side)
>        E6) ConnectRetry timer expired
>        E7) Disable MSDP peering with P
>            (e.g. when one's own address is changed)
>        E8) Hold Timer expired
>        E9) MSDP TLV format error detected
>       E10) Any other error detected

It seems that the FSM is not normalized, specifically the INACTIVE
state seems redundant--it is not a "stable" state and the FSM
transitions either to CONNECTING or LISTEN directly depending on the
IP address comparison.

Am I missing something?

...

> 15. Packet Formats
> 
>    MSDP messages will be encoded in TLV format. If an implementation
>    receives a TLV that has length that is longer than expected, the TLV
>    SHOULD be accepted. Any additional data SHOULD be ignored and the
>    MSDP session should not be reset.
> 
> 
> 15.1. MSDP TLV format:
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Type       |           Length              |  Value ....   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Type (8 bits)
>     Describes the format of the Value field.
> 
>    Length (16 bits)
>     Length of Type, Length, and Value fields in octets.
>     Minimum length required is 4 octets, except for
>     Keepalive messages.  The maximum TLV length is 9192.
> 
>    Value (variable length)
>     Format is based on the Type value. See below. The length of
>     the value field is Length field minus 3. All reserved fields
>     in the Value field MUST be transmitted as zeros and ignored on
>     receipt.
> 
> 
> 15.2. Defined TLVs
> 
>    The following TLV Types are defined:

Do we want IANA to maintain a registry for this?

> 
>    Code                                  Type
>    ===========================================================
>     1                  IPv4 Source-Active
>     2                  IPv4 Source-Active Request
>     3                  IPv4 Source-Active Response
>     4                  KeepAlive
>     5                  Reserved (Previously: Notification)
> 
>    Each TLV is described below.
> 
>    In addition, the following TLV Types are assigned but not described
>    in this memo:
> 
>    Code                                  Type
>    ===========================================================
>     6                  MSDP traceroute in progress
>     7                  MSDP traceroute reply

Where are they described though?

> 
> 15.2.1. IPv4 Source-Active TLV
> 
>    The maximum size SA message that can be sent is 9192 octets. The 9192
>    octet size does not include the TCP, IP, layer-2 headers.
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       1       |           x + y               |  Entry Count  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          RP Address                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Reserved            |  Sprefix Len  | \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  \
>    |                         Group Address                         |   ) z
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  /
>    |                         Source Address                        | /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Type
>     IPv4 Source-Active TLV is type 1.
> 
>    Length x
>     Is the length of the control information in the message. x is
>     8 octets (for the first two 32-bit quantities) plus 12 times
>     Entry Count octets.
> 
>    Length y
>     If 0, then there is no data encapsulated. Otherwise an IPv4
>     packet follows and y is the length of the total length field

the _value_ of the total length field?

>     of the IPv4 header encapsulated.

in the header of the encapsulated IP packet?

>  If there are multiple SA TLVs
>     in a message, and data is also included, y must be 0 in all SA
>     TLVs except the last one and the last SA TLV must reflect the
>     source and destination addresses in the IP header of the
>     encapsulated data.

What does "a message" and "the last TLV in the message" really
mean given that MSDP uses stream transport?
Is TCP segment meant? Note that the receiver has no visibility
to TCP segmentation details...

>    Entry Count
>     Is the count of z entries (note above) which follow the RP
>     address field. This is so multiple (S,G)s from the same domain
>     can be encoded efficiently for the same RP address.  An
>     SA message containing encapsulated data typically has an

SA message??? or TLV?

>     entry count of 1 (i.e. only contains a single entry, for
>     the (S,G) representing the encapsulated packet).
> 
>    RP Address
>     The address of the RP in the domain the source has become
>     active in.
> 
>    Reserved
>     The Reserved field MUST be transmitted as zeros and MUST be
>     ignored by a receiver.
> 
>    Sprefix Len
>     The route prefix length associated with source address.
>     This field MUST be transmitted as 32 (/32).
> 
>    Group Address
>     The group address the active source has sent data to.
> 
>    Source Address
>     The IP address of the active source.
> 
>    Multiple SA TLVs MAY appear in the same message and can be batched

Message again? Meaning TCP segment?

>    for efficiency at the expense of data latency. This would typically
>    occur on intermediate forwarding of SA messages.
> 
> 
> 15.2.2. KeepAlive TLV
> 
> 
>    A KeepAlive TLV is sent to an MSDP peer if and only if there were no
>    MSDP messages sent to the peer within [KeepAlive-Period] seconds.
>    This message is necessary to keep the MSDP connection alive.
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       4       |             3                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The length of the message is 3 octets which encompasses the one octet
>    Type field and the two octet Length field.
> 
> 
> 16. MSDP Error Handling
> 
>    If an MSDP SA is received with a TLV format error, the session SHOULD
>    be reset with that peer. All other errors, received from MSDP peers,
>    SHOULD silently discard the packets and the session SHOULD not be
> reset.

"errors should discard..." sounds weird.
also, why is TLV format error causes session reset for SA TLV only?
When TLV error is detected, it is practically impossible to resync
the session without a sequence of flags, and it is not safe to trust
the data if it possible that the stream is out of sync, i.e., any
TLV format error should reset the session...

> 17. SA Data Encapsulation
> 
>    As discussed earlier, TCP encapsulation of data in SA messages MAY be
>    supported for backwards compatibility with legacy MSDP peers.
> 
> 
> 18. Security Considerations
> 
>    An MSDP implementation MAY use IPsec [RFC2401] or MD5 to secure control
>    messages. In particular, the TCP connection between MSDP peers MAY
>    be secured using IPsec or MD5. Implementations MUST be capable of
>    working with peers which do not provide IPsec or MD5 security.

Ref to the TCP-MD5 RFC?

It seems that a threat analysis maybe required for the Security
Considerations section to be useful. On the other hand, this is going
Exp, so maybe this is enough...

Thanks.

Alex

===8<===========End of original message text===========