RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt

Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document!

All,

we have a consensus on making
draft-yasukawa-mpls-p2mp-requirement-01.txt
a working group document.

Will be published shortly.

--

-- 

Loa Andersson

mobile +46 739 81 21 64

Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document

All,

we've the a consensus on making the

draft-farrel-mpls-rsvpte-attributes-00.txt

an mpls working group document, will be published shortly.

/Loa

--

-- 

Loa Andersson

mobile +46 739 81 21 64

draft-ietf-mpls-ldp-mtu-extensions-02.txt implementations?

All,

we have requested an IESG review of

draft-ietf-mpls-ldp-mtu-extensions-02.txt

to become a proposed standard, the ADs have
notified us that we need to have a known implementation
in order to progress it.

We therefore solicit information on implentations
of this spec.

/Loa

--

-- 

Loa Andersson

mobile +46 739 81 21 64

Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt

All,

I have published a draft to start the ball rolling in the great hard/soft pre-emption
debate.
There is no doubt that the draft is rambling and wrong.

Please enter into a detailed and heated debate.

In summary...

The points of contention are:
- Should pre-emption cause the associated LSP to be torn down
  - at the point of pre-emption
  - at all other LSRs along the LSP?
- If it is torn down, is it torn using PathErr and ResvErr?
- What is the correct processing of a PathErr after an LSP has
   been successfully established.
- Is it possible for hard and soft pre-emption to co-exist in a
   network if they both use the same signalling technique?

A lot of the answers seem to hang on how admission control is performed. Is it per LSP or
is it statistical?

It does not appear to be very fruitful to investigate
- the 'correct' interpretation of RFC3209
- the motivation for the Path_State_Removed flag in RFC3473
(You are, however, perfectly free to investigate whatever you like!)

Cheers,
Adrian

----- Original Message ----- 
From: <Internet-Drafts <at> ietf.org>
To: <IETF-Announce:>
Sent: Tuesday, December 02, 2003 8:35 PM
Subject: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Interim Report on MPLS Pre-emption
> Author(s) : A. Farrel
> Filename : draft-farrel-mpls-preemption-interim-00.txt
> Pages : 0
> Date : 2003-12-2
>
> This document is an interim report into pre-emption in MPLS systems.
>
> At the 58th IETF, the MPLS Working Group determined that there are
> several interpretations of how pre-emption should be achieved within
> MPLS systems. This document is the result of the initial enquiries to
> vendors and other implementors into the question of how and why they
> offer pre-emption funtion in their MPLS inplementations.
>
> This document is intended to be a short-lived document and only
> exists to document the current findings. It will be superceded or
> retired.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-preemption-interim-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-preemption-interim-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv <at> ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-farrel-mpls-preemption-interim-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

Re: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt

On Tue, 2 Dec 2003, Adrian Farrel wrote:

> Please enter into a detailed and heated debate.

I will be helpful and not comment.  But it is soooo tempting! 

Kireeti.
-------

Re: Fw: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt

Kireeti wrote.

> > Please enter into a detailed and heated debate.
> 
> I will be helpful and not comment.  But it is soooo tempting! 

Really?

Are you unwell?

I do hope your soon restored to your usual, trouble making self.

Adrian

Re: DT's review of draft-ietf-mpls-telink-mib-04.txt

Dave,

I have studied your response in greater details.

I have an issue with the last part of point number 4. Your layering proposal
is not in line with the intent of the TE link MIB. TE links are really
logical entities used to present a set of one or more network resources with
a consistent set of characteristics. By allowing a TE link to be either a TE
link or a tunnel, we are breaking this paradigm. TE links would be in some
cases logical entities, and in other cases "physical" entities (or should I
say real network resources).

For consistency, I would like to see tunnels handled the same as other
technologies. In the example that you present, I would like to see the
layering as follows:

+-----------------------------------+
MPLS interface ifType = mpls(166)
+-----------------------------------+
TE link ifType = TE link(200)
+-----------------------------------+
Component link
Tunnel link ifType = tunnel(131)
+-----------------------------------+
ifType = ethernetCsmacd(6)
+-----------------------------------+

Martin

----- Original Message -----
From: "Dave Thaler" <dthaler <at> windows.microsoft.com>
To: "Mpls (E-mail)" <mpls <at> uu.net>
Cc: "Bert Wijnen" <bwijnen <at> lucent.com>
Sent: Wednesday, November 26, 2003 7:41 PM
Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt

Bert asked me to post the current status of the telink-mib discussion.
Since a new version hasn't been submitted since my initial review, I'll
briefly summarize where I think we are on draft-04.

1) Relationship between teLinkLocalIpAddr and ipAddrTable needs to be
   clarified, and authors agreed.

   On Oct. 22, 2003, Martin Dubuc wrote:
   > I will add text in the DESCIRPTION clause to emphasize the
   > relationship between teLinkLocalIpAddr and ipAddrTable.

2) teLinkIncomingIfId should have
        SYNTAX Integer32 (0..2147483647)
   instead of
        SYNTAX InterfaceIndexOrZero

    On Oct. 6, 2003, Martin wrote:
    > I can make this change.

3) teLink{Outgoing,Incoming}IfId descriptions should be more clear:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. For numbered links, the address is
            stored in the teLinkLocalIpAddr instead."
    It is unclear what is meant by "instead".  If the value here should
    be 0, say that explicitly, as in:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. If the link is numbered, the value
is
            0."

    On Oct. 6, 2003, Martin wrote:
    > I can be explicit as you suggest.

4) Requirements from section 4 of RFC 2863 not met yet in section 8 are:

   ifRcvAddressTable
      The media-specific MIB designer MUST specify the applicability of
      the ifRcvAddressTable.

   ifXxxOctets
      The definitions of ifInOctets and ifOutOctets (and similarly,
      ifHCInOctets and ifHCOutOctets) specify that their values include
      framing characters.  The media-specific MIB designer MUST specify
      any special conditions of the media concerning the inclusion of
      framing characters, especially with respect to frames with errors.

   I have seen no response from the authors yet on this point.

5) On the topic of extending the tunnel MIB, I believe everyone agreed
   on the following points:

    a) Some objects are redundant with the IP Tunnel MIB (RFC 2667) in
       the case where the MPLS TE link is a tunnel over IPv4.  These
       redundant objects are useful when the agent does not support the
       IP tunnel MIB, or when the tunnel is over IPv6, which is not yet
       handled by 2667.

    b) Regardless of what happens with this MIB, RFC 2667 should be
updated
       to handle IPv6.  (This was done,
draft-thaler-inet-tunnel-mib-00.txt
       was posted to the ifmib and ipv6 lists, presented in the IPv6 WG
       in Minneapolis and was accepted as an IPv6 WG item since the
IFMIB
       WG is closed.)

    c) It would be good to be done with the MPLS TE link MIB now and
       not be blocked on any other document.

   To briefly change the subject to an analogous issue, Kireeti, Bert,
   and I met at IETF to talk about a similar issue in the TEWG MIB.
   We concluded that the best answer was to allow the MIB to be used
   both for tunnels (where it can logically extend the tunnel MIB)
   as well as for non-tunnel objects, where it does not extend the
   tunnel MIB.  This can be done in such a way as to not change anything
   in the MIB definition itself, just the intro text in the document.

   I think this same solution can be used in the MPLS TElink MIB, and
   hence solve the problems of not being able extend the tunnel MIB
   when an agent supports it.

   Hence we could add a small subsection to section 8 along the lines
of:

    8.1 Application of the IP Tunnel MIB to TE Links

    The IP Tunnel MIB [RFC2667] defines managed objects for managing
    tunnels over IP. For TE Link interfaces which correspond to tunnels
    over IP, an agent supporting the IP Tunnel MIB would have entries in

    that MIB for TE tunnels. Interfaces in the IP Tunnel MIB use ifType
=
    tunnel (131), and have a subtype identifying the actual
encapsulation
    method.  Hence, in the case where MPLS is using a single TE tunnel
    link, the interface stack might appear as (for example):

        +-----------------------------------+
        | MPLS interface ifType = mpls(166) |
        +-----------------------------------+
        | Tunnel link ifType = tunnel(131)  |
        +-----------------------------------+
        | Underlying Layer...               |
        | ifType = ethernetCsmacd(6)        |
        +-----------------------------------+

   [Note: I'm not sure whether the above stack is correct, since I'm
   not sure what data encapsulation is used on the wire.  The above
   stack would be correct if an actual data packet on the wire looked
like:

      Ethernet - Outer IPv4 - MPLS - Inner IPv4 - payload

   If the packet looks different, the stack would be different.]

   Also update the DESCRIPTION clauses of teLinkEntry,
   teLinkDescriptorEntry, teLinkSrlgEntry, teLinkBandwidthEntry
   which all say ifType must be 200, to say 200 or 131.

   This would allow the TE link mib to be used both ways, and hence
   allow the benefits of the tunnel MIB, without requiring it or any
   other changes to an existing implementation.

   The alternative would be to publish without this now and rev the
   TE Link MIB at the same time as the Inet Tunnel MIB would go to RFC.

-Dave

I-D ACTION:draft-ietf-mpls-p2mp-requirement-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Requirements for Point to Multipoint extension to RSVP-TE
	Author(s)	: S. Yasukawa
	Filename	: draft-ietf-mpls-p2mp-requirement-00.txt
	Pages		: 20
	Date		: 2003-12-4
	
This document presents a set of requirements for Point-to-Multipoint
(P2MP) Traffic Engineering (TE) extensions to Multiprotocol Label
Switching (MPLS). It specifies functional requirements for RSVP-TE in
order to deliver P2MP applications over a MPLS TE infrastructure. It
is intended that potential solutions, that specify RSVP-TE procedures
for P2MP TE LSP setup, use these requirements as a guideline. It is
not intended to specify solution specific details in this document.
It is intended that the requirements presented in this document are
not limited to the requirements of packet switched networks, but also
encompass the requirements of TDM, lambda and port switching networks
managed by Generalized MPLS (GMPLS) protocols. Protocol solutions
developed to meet the requirements set out in this document must be
equally applicable to MPLS and GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-requirement-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-p2mp-requirement-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-p2mp-requirement-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: Last Call: Procedures for Modifying RSVP to a BCP

> All,
> I am not sure I fully understand what is being proposed by this
> document in terms of values to be assigned to RSVP entities for
> standards organizations outside of IETF. In section 1, there is
> the paragraph:
> 
> "  A standards body other than the IETF that wishes to obtain an
>    assignment for an RSVP entity must decide from which type of
>    name/number space they desire their assignment be made from, and then
>    submit the appropriate documentation."
> 
> I would suppose that "appropriate documentation" is to leave the
> door open that we eventually have a real liaison process by which
> an incoming liaison statement has some sort of status within IETF,
> and I have no difficulty leaving the language here loose enough to
> accomodate this possibility.
> 
> However I have more difficulty later on understanding what ranges
> would apply for RSVP entities defined by standards bodies outside
> of IETF. These would not seem to meet the "vendor private use" or
> "expert review" categories, so by process of elimination, they
> would seem to be "standards action" assignments.
> 
> However, it is not generally a good idea to have more than one
> normative source for a particular standards element. If a specification
> appears in more than one place, it should be clear which is the
> controlling document (which one should be paid attention to if
> the specifications differ) and where someone should go in order
> to propose changes.
> 
> What we have done in the past with these sorts of things is to have
> an informational RFC in IETF that references the external standard.
> But in reading this document, it seems that "standards action"
> codepoints could only be assigned to values for standards track
> RFCs within IETF.
> 
> I think the document needs to be clearer about assignment of
> codepoints for RSVP entities defined by other standards bodies.
> If approving an informational RFC as we have done in the past is
> considered to be some kind of standards action, and can therefore
> be used for these kinds of assignments, I think a few more words are
> needed to clarify that we can still do these things as in the past.
> 
> But if the intent is that any such assignments in the future actually
> be in standards track RFCs, then we have the problem of multiple
> normative sources, and I think more discussion is needed to make
> sure that this is really what we want.
> 
> If the procedures to be followed by other standards organizations are
> to change, it will also be necessary to comminucate that change
> to those other organizations so that they will know the appropriate
> procedure to follow for their applications of RSVP.
> Regards,
> Steve
>