The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Jun> msg00139



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Contents of mpls digest...Vol 26

  • From: sanjay.chalikar@vsnl.net
  • Date: Sat, 24 Jun 2006 15:51:44 +0500

I am not abe to find the file stated "Filename : draft-ietf-mpls-mp-ldp-reqs-01.txt" can i be guided ?

with kind regards,

Sanjay Chalikar (m) 9223468245.




with kind regards,
Sanjay Chalikar
(m) 9223 468245.

Today's Topics:

   1. I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt 
      (Internet-Drafts@ietf.org)
   2. RE: TR: working group last call
      ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (LE ROUX Jean-Louis RD-CORE-LAN)
   3. RE: TR: working group last call
      ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (Lou Berger)
   4. Load-Balancing among a set of candidate upstream LSRs on a
      LAN-----draft-liu-mpls-upstream-load-balance-00.txt (liushuying)
   5. RE: TR: working group last call
      ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (LE ROUX Jean-Louis RD-CORE-LAN)


  • From: Internet-Drafts@ietf.org
  • Date: Thu, 22 Jun 2006 18:50:01 -0400
  • Cc: mpls@lists.ietf.org
  • Message: 1
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Requirements for point-to-multipoint 
                          extensions to the Label Distribution Protocol
	Author(s)	: J. Le Roux, et al.
	Filename	: draft-ietf-mpls-mp-ldp-reqs-01.txt
	Pages		: 17
	Date		: 2006-6-22
	
This document lists a set of functional requirements for Label 
   Distribution Protocol (LDP) extensions for setting up point-to-
   multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 
   point-to-multipoint applications over a Multi Protocol Label 
   Switching (MPLS) infrastructure. It is intended that solutions that 
   specify LDP procedures for setting up P2MP LSP satisfy these 
   requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-mp-ldp-reqs-01.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@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.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.

<<< multipart/alternative: No recognizable part >>>




  • From: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@orange-ft.com>
  • Date: Thu, 22 Jun 2006 16:02:39 +0200
  • Cc: mpls@ietf.org, "Drake, John E" <John.E.Drake2@boeing.com>
  • Message: 2
Hi Rahul,

>Would you like to propose the modified text ? 

I can provide some text by the end of the day.

Regards,

JL


> -----Message d'origine-----
> De : Rahul Aggarwal [mailto:rahul@juniper.net] 
> Envoyé : jeudi 22 juin 2006 15:53
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : mpls@ietf.org; Drake, John E
> Objet : RE: [mpls] TR: working group last call 
> ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> 
> Hi JL,
> 
> On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> > Hi Rahul, all
> >
> > Actually, after thinking a bit more, it seems to me that a 
> simpler remerge procedure based on RRO analysis could be useful.
> > If the RRO is carried in Path messages, the node where the remerge 
> > occurs could easily identify the node that created the 
> remerge, simply by analyzing the two RROs.
> > When a node detect a remerge it sends a PAthErr with a new 
> object (Remerge-Spec object) that identifies the remerge 
> origin. This PathErr carries the set of sub-LSPs received in 
> the Path message that caused the remerge.
> > On receipt of such PAthErr, a node that see its own address in the 
> > Remerge-spec object moves the set of sub-LSPs...
> >
> > It seems that this procedure would require simpler processing...
> > It requires the use of RRO, but this is the price to pay.
> >
> 
> I think this is reasonable. If it is desriable to fix remerge 
> in the control plane this is a reasonable tradeoff. Else the 
> spec has the option to fix remerge in the data plane.
> 
> > Would that make sense?
> >
> 
> Would you like to propose the modified text ?
> 
> Thanks,
> rahul
> 
> > Best Regards,
> >
> > JL
> >
> >
> > > -----Message d'origine-----
> > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] 
> Envoyé : mardi 
> > > 20 juin 2006 23:59 À : zzx-rahul@juniper.net; LE ROUX Jean-Louis 
> > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR: 
> working group 
> > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > Rahul,
> > >
> > > Snipped, comments inline.
> > >
> > > Thanks,
> > >
> > > John
> > > > > > 4: Section 18.1.1 Remerge Procedure
> > > > > >
> > > > > > The text says
> > > > > >    "The PathErr message MUST include all of the objects
> > > > > >    normally included in a PathErr message, as well as
> > > one or more
> > > SUB-
> > > > > >    LSP objects from the set of sub-LSPs associated with the
> > > matching
> > > > > >    P2MP LSP Path state.  A minimum of three SUB-LSP 
> objects is
> > > > > >    RECOMMENDED. This will allow the node that caused
> > > the re-merge
> > > to
> > > > > >    identify the outgoing Path state associated with 
> the valid 
> > > > > > portion of
> > > > > >    the P2MP LSP. The set of SUB-LSP objects in the
> > > received Path
> > > > > > message
> > > > > >    MUST also be included"
> > > > > >
> > > > > > And then:
> > > > > >
> > > > > >    "A node that receives a PathErr message that
> > > contains the Error
> > > > > > Value
> > > > > >    "Routing Problem/P2MP Remerge Detected" MUST
> > > determine if it is
> > > the
> > > > > >    node that created the re-merge case.  This is done
> > > by checking
> > > > > >    whether there is any intersection between the set of 
> > > > > > SUB-LSP objects
> > > > > >    associated with the matching P2MP LSP Path state and
> > > the set of
> > > > > > SUB-
> > > > > >    LSP objects in the received PathErr message.  If
> > > there is, then
> > > the
> > > > > >    node created the re-merge case."
> > > > > >
> > > > > > There is an issue here. Actually there will always be an 
> > > > > > intersection, because the PathErr includes the set 
> of sub-lsp 
> > > > > > objects in the received Path... IMO for this procedure
> > > to work the
> > > > > > PathErr MUST only include sub-LSP objects 
> associated with the 
> > > > > > matching P2MP LSP state on the rermerge LSR and must
> > > not include
> > > > > > the set of SUB-LSP objects in the received Path message.
> > > > > > By the way why are three objects recommended?
> > > > > >
> > > >
> > > > I believe this was clarified by John Drake offline and no 
> > > > revisions
> > > were
> > > > needed ?
> > > Rahul,
> > >
> > > Here's the e-mail I sent to JL:
> > >
> > > "JL,
> > >
> > > The text was originally stated as you stated.  The issue 
> is that the 
> > > set of sub-LSPs associated with the interface on the node that 
> > > caused the re-merge condition may have more members than 
> the set of 
> > > sub-LSPs in the received Path message, and you only want 
> to move the 
> > > ones that were in the received Path message.
> > >
> > > Adrian was the one who initially pointed this and he proposed 
> > > creating a different object/type for the set of sub-LSPs in the 
> > > received Path message. I think this is reasonable solution.
> > >
> > > Thanks,
> > >
> > > John"
> > >
> > > As you can see from the last paragraph, we do need to 
> create a new 
> > > object/type.
> > >
> >
> >
>




  • From: Lou Berger <lberger@labn.net>
  • Date: Thu, 22 Jun 2006 23:51:22 -0400
  • Cc: mpls@ietf.org, "Drake, John E" <John.E.Drake2@boeing.com>
  • Message: 3
JL,

So what happens when no RRO is used (which isn't 
currently required) or portions of the RRO are removed?

Lou

At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

>Hi Rahul, all
>
>Actually, after thinking a bit more, it seems to 
>me that a simpler remerge procedure based on RRO analysis could be useful.
>If the RRO is carried in Path messages, the node where the remerge
>occurs could easily identify the node that 
>created the remerge, simply by analyzing the two RROs.
>When a node detect a remerge it sends a PAthErr 
>with a new object (Remerge-Spec object) that 
>identifies the remerge origin. This PathErr 
>carries the set of sub-LSPs received in the Path 
>message that caused the remerge.
>On receipt of such PAthErr, a node that see its own address in the
>Remerge-spec object moves the set of sub-LSPs...
>
>It seems that this procedure would require simpler processing...
>It requires the use of RRO, but this is the price to pay.
>
>Would that make sense?
>
>Best Regards,
>
>JL
>
>
> > -----Message d'origine-----
> > De : Drake, John E [mailto:John.E.Drake2@boeing.com]
> > Envoyé : mardi 20 juin 2006 23:59
> > À : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN
> > Cc : mpls@ietf.org
> > Objet : RE: [mpls] TR: working group last call
> > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > Rahul,
> >
> > Snipped, comments inline.
> >
> > Thanks,
> >
> > John
> > > > > 4: Section 18.1.1 Remerge Procedure
> > > > >
> > > > > The text says
> > > > >    "The PathErr message MUST include all of the objects
> > > > >    normally included in a PathErr message, as well as
> > one or more
> > SUB-
> > > > >    LSP objects from the set of sub-LSPs associated with the
> > matching
> > > > >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> > > > >    RECOMMENDED. This will allow the node that caused
> > the re-merge
> > to
> > > > >    identify the outgoing Path state associated with the valid
> > > > > portion of
> > > > >    the P2MP LSP. The set of SUB-LSP objects in the
> > received Path
> > > > > message
> > > > >    MUST also be included"
> > > > >
> > > > > And then:
> > > > >
> > > > >    "A node that receives a PathErr message that
> > contains the Error
> > > > > Value
> > > > >    "Routing Problem/P2MP Remerge Detected" MUST
> > determine if it is
> > the
> > > > >    node that created the re-merge case.  This is done
> > by checking
> > > > >    whether there is any intersection between the set of SUB-LSP
> > > > > objects
> > > > >    associated with the matching P2MP LSP Path state and
> > the set of
> > > > > SUB-
> > > > >    LSP objects in the received PathErr message.  If
> > there is, then
> > the
> > > > >    node created the re-merge case."
> > > > >
> > > > > There is an issue here. Actually there will always be an
> > > > > intersection, because the PathErr includes the set of sub-lsp
> > > > > objects in the received Path... IMO for this procedure
> > to work the
> > > > > PathErr MUST only include sub-LSP objects associated with the
> > > > > matching P2MP LSP state on the rermerge LSR and must
> > not include
> > > > > the set of SUB-LSP objects in the received Path message.
> > > > > By the way why are three objects recommended?
> > > > >
> > >
> > > I believe this was clarified by John Drake offline and no revisions
> > were
> > > needed ?
> > Rahul,
> >
> > Here's the e-mail I sent to JL:
> >
> > "JL,
> >
> > The text was originally stated as you stated.  The issue is
> > that the set of sub-LSPs associated with the interface on the
> > node that caused the re-merge condition may have more members
> > than the set of sub-LSPs in the received Path message, and
> > you only want to move the ones that were in the received Path message.
> >
> > Adrian was the one who initially pointed this and he proposed
> > creating a different object/type for the set of sub-LSPs in
> > the received Path message. I think this is reasonable solution.
> >
> > Thanks,
> >
> > John"
> >
> > As you can see from the last paragraph, we do need to create
> > a new object/type.
> >
>
>_______________________________________________
>mpls mailing list
>mpls@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/mpls




  • From: liushuying <lshuying@huawei.com>
  • Date: Fri, 23 Jun 2006 15:13:40 +0800
  • Message: 4
Hi folks.
    A New Internet-Draft is available from the on-line Internet-Drafts directories.
The draft can be found here:
 
 
Title : Load-Balancing among a set of candidate upstream LSRs on a LAN
Author(s) : Shuying Liu
Filename : draft-liu-mpls-upstream-load-balance-00.txt
Pages : 7
Date : 2006-06-16
 
This document describes a mechanism for Load-Balancing among a set of 
candidate upstream LSRs on a LAN interface. When there are several 
candidates to be selected as an upstream LSR, according the current 
upstream label allocation methods, the load on the candidate upstream 
LSR which is selected by the routing protocol may be very heavy, 
while the load on other candidate upstream LSRs is little. The Load-
Balancing also provides some procedures to minimize the packet loss 
in following cases: 1) adding/removing a candidate upstream LSR; 2) a 
better path emerging.
 
Please give your comments on this document! Thank you very much.
 
Best regards
Shuying Liu
HuaWei Bld., No.3 Xinxi Rd.,  
Shang-Di Information Industry Base,            
Hai-Dian District Beijing P.R. China
ZIP£º100085 





  • From: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@orange-ft.com>
  • Date: Fri, 23 Jun 2006 09:20:57 +0200
  • Cc: mpls@ietf.org, "Drake, John E" <John.E.Drake2@boeing.com>
  • Message: 5
Hi Lou,

When RRO is not used this procedure does not apply and remerge should be fixed in the data plane on the remerge node. 

IMO full RRO inclusion is the price to pay if you want to fix remerge in a simple manner in the control plane.

Regards,

JL

> -----Message d'origine-----
> De : Lou Berger [mailto:lberger@labn.net] 
> Envoyé : vendredi 23 juin 2006 05:51
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E
> Objet : RE: [mpls] TR: working group last call 
> ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> JL,
> 
> So what happens when no RRO is used (which isn't currently 
> required) or portions of the RRO are removed?
> 
> Lou
> 
> At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> >Hi Rahul, all
> >
> >Actually, after thinking a bit more, it seems to me that a simpler 
> >remerge procedure based on RRO analysis could be useful.
> >If the RRO is carried in Path messages, the node where the remerge 
> >occurs could easily identify the node that created the 
> remerge, simply 
> >by analyzing the two RROs.
> >When a node detect a remerge it sends a PAthErr with a new object 
> >(Remerge-Spec object) that identifies the remerge origin. 
> This PathErr 
> >carries the set of sub-LSPs received in the Path message that caused 
> >the remerge.
> >On receipt of such PAthErr, a node that see its own address in the 
> >Remerge-spec object moves the set of sub-LSPs...
> >
> >It seems that this procedure would require simpler processing...
> >It requires the use of RRO, but this is the price to pay.
> >
> >Would that make sense?
> >
> >Best Regards,
> >
> >JL
> >
> >
> > > -----Message d'origine-----
> > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] 
> Envoyé : mardi 
> > > 20 juin 2006 23:59 À : zzx-rahul@juniper.net; LE ROUX Jean-Louis 
> > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR: 
> working group 
> > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > Rahul,
> > >
> > > Snipped, comments inline.
> > >
> > > Thanks,
> > >
> > > John
> > > > > > 4: Section 18.1.1 Remerge Procedure
> > > > > >
> > > > > > The text says
> > > > > >    "The PathErr message MUST include all of the objects
> > > > > >    normally included in a PathErr message, as well as
> > > one or more
> > > SUB-
> > > > > >    LSP objects from the set of sub-LSPs associated with the
> > > matching
> > > > > >    P2MP LSP Path state.  A minimum of three SUB-LSP 
> objects is
> > > > > >    RECOMMENDED. This will allow the node that caused
> > > the re-merge
> > > to
> > > > > >    identify the outgoing Path state associated with 
> the valid 
> > > > > > portion of
> > > > > >    the P2MP LSP. The set of SUB-LSP objects in the
> > > received Path
> > > > > > message
> > > > > >    MUST also be included"
> > > > > >
> > > > > > And then:
> > > > > >
> > > > > >    "A node that receives a PathErr message that
> > > contains the Error
> > > > > > Value
> > > > > >    "Routing Problem/P2MP Remerge Detected" MUST
> > > determine if it is
> > > the
> > > > > >    node that created the re-merge case.  This is done
> > > by checking
> > > > > >    whether there is any intersection between the set of 
> > > > > > SUB-LSP objects
> > > > > >    associated with the matching P2MP LSP Path state and
> > > the set of
> > > > > > SUB-
> > > > > >    LSP objects in the received PathErr message.  If
> > > there is, then
> > > the
> > > > > >    node created the re-merge case."
> > > > > >
> > > > > > There is an issue here. Actually there will always be an 
> > > > > > intersection, because the PathErr includes the set 
> of sub-lsp 
> > > > > > objects in the received Path... IMO for this procedure
> > > to work the
> > > > > > PathErr MUST only include sub-LSP objects 
> associated with the 
> > > > > > matching P2MP LSP state on the rermerge LSR and must
> > > not include
> > > > > > the set of SUB-LSP objects in the received Path message.
> > > > > > By the way why are three objects recommended?
> > > > > >
> > > >
> > > > I believe this was clarified by John Drake offline and no 
> > > > revisions
> > > were
> > > > needed ?
> > > Rahul,
> > >
> > > Here's the e-mail I sent to JL:
> > >
> > > "JL,
> > >
> > > The text was originally stated as you stated.  The issue 
> is that the 
> > > set of sub-LSPs associated with the interface on the node that 
> > > caused the re-merge condition may have more members than 
> the set of 
> > > sub-LSPs in the received Path message, and you only want 
> to move the 
> > > ones that were in the received Path message.
> > >
> > > Adrian was the one who initially pointed this and he proposed 
> > > creating a different object/type for the set of sub-LSPs in the 
> > > received Path message. I think this is reasonable solution.
> > >
> > > Thanks,
> > >
> > > John"
> > >
> > > As you can see from the last paragraph, we do need to 
> create a new 
> > > object/type.
> > >
> >
> >_______________________________________________
> >mpls mailing list
> >mpls@lists.ietf.org
> >https://www1.ietf.org/mailman/listinfo/mpls
> 
> 





_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls