From mpls-bounces@lists.ietf.org Mon May 02 06:14:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSXwq-0002OS-FS; Mon, 02 May 2005 06:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSXwo-0002OL-7z for mpls@megatron.ietf.org; Mon, 02 May 2005 06:14:42 -0400 Received: from hotmail.com (bay21-dav18.bay21.hotmail.com [65.54.233.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23498 for ; Mon, 2 May 2005 06:14:39 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 May 2005 03:16:13 -0700 Message-ID: Received: from 57.250.229.136 by BAY21-DAV18.phx.gbl with DAV; Mon, 02 May 2005 10:16:13 +0000 X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. elk" To: Date: Mon, 2 May 2005 14:23:02 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 May 2005 10:16:13.0696 (UTC) FILETIME=[F8288800:01C54EFF] Cc: Subject: [mpls] Clarfication reg LSP PING - Draft ver 08-Part 1/3 . X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0569532295==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0569532295== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01C54F22.73022550" This is a multi-part message in MIME format. ------=_NextPart_000_01B5_01C54F22.73022550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Part 1 of 3 . Hi=20 Appreciate U clarification for below : A- Section 3 , Packet Format=20 A1. For "If the normal IP return path is deemed unreliable ,one may use = "Reply=20 via an IPV4/IPV6 UDP Packet with Router Alert " .=20 =20 Actually it was not clear how using such mode of reply will = increase the chance to receive the=20 reply packet . In some external presentation , it is explained as = the reply will be routed in a=20 transient LSR by the RP(instead of the LC ) and as such the reply = packet will be correctly=20 routed in the case where the FIB of the LC is corrupted . May be it = worth to document this=20 explanation into the draft . What about "Reply and log " , in this case the operator could check = the remote end to see if any=20 log in case of no reply received . For sacalability , The receiving = station count the nbr of echo=20 request for each (Source IP Address,Source UDP port , Sender = Handle).=20 and/or "Reply Via NMS" ,path from any node to NMS is the most=20 watched path (from OPS perspective) and we could assume it is up=20 (otherwise it is currently under attention of the operator ) . In = this mode the node=20 encapsulate the reply in IP-in-IP through the NMS .=20 A2.For "TLVs may be nested within other TLV ......"=20 The above indicate that we could liberally nest TLV within TLV , = but actually it is not the case . We do have strict TLV and SUB-TLV as the "Type" field of the TLV = and SUB-TLV do Overlap . =20 In other word : TLV could not appear inside another TLV . SUB-TLV = could not appear unless inside=20 TLV .=20 =20 A3. For Target-FEC-Stack TLV contain 1) Sub-TLV LDP IPv4 and 2)Sub-TLV = VPN IPV4 Prefix the length could be : i) 24 or j) 20 ? =20 For 24 , each SUB-TLV is aligned to four-octet-boundary . For 20 , the TLV ( as a whole) is aligned to four-octet-boundary If the draft recommend the way to align each sub-TLV to = four-octet-boundary(length =3D 24) ,but in=20 such case why the length value of the SUB-TLV was chosen not to = include the padding byte ??=20 ex: For LDP IPv4 the length is 5 instead of 8 . The "length" field = should specify the actual size=20 (in this case 8) used on the wire , the receiving node from the = "Type" field could determine that=20 the used part is just 5 . =20 Else (length =3D 20) , could we modify the example to include more = than one Sub-TLV to make the=20 case clearer . A4. For the Para (page 10) "Types less than 32768 ....etc " .=20 may be changing the word "mandatory" to "mandatory supported " . For the Para (page 10) "Types greater than .....etc " . may be changing the word "optional " to "optionally supported" = =20 This will make it more clear that "mandatory" and "optional" refer = to the support of the node for=20 such TLV's and not the existence of such TLV in the packet . =20 A5. Section 3.2 page 12 . for the Sub-TLV "RSVP IPv4 Session Query" , better to be named as = just "RSVP IPv4 Session" . =20 same for IPv6 . A6. Page 12 , the Para "say LSR X wanted ...etc ".=20 is this applicable to "LSP Trace" also ??? For the case where RSVP Tunnel end at the destination PE (Target = FEC TLV could contain RSVP IPV4=20 session Sub-TLVand IP VPN Prefix Sub-TLV. or Target FEC could = contain just the IP VPN Prefix Sub-TLV ) , is it workable for "LSP Trace". =20 (The point that in case the target FEC contain just the IP VPN = Sub-TLV , the transient LSR will find no =20 Sub-TLV FEC which correspond to the RSVP LSP or the LDP LSP so how = this LSR could check ) . The confusing point that a transient LSR in some cases is able to = check the received label against the=20 target FEC ,and in other cases it is not possible . Is it correct = ??=20 If yes : How the transient LSR could differentiate . =20 N.B: may be the answer to above is within section 4.4 (Receiving = an MPLS echo request) ,but i am having=20 difficulty to understand section 4.4 . =20 A7. NIL FEC=20 One usage for "NIL FEC" is documented in section 4.2 . Any other = usage not documented in the draft ??? Brgds ------=_NextPart_000_01B5_01C54F22.73022550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Part 1 of 3 .
Hi
 
Appreciate U clarification for below :
 
A- Section 3 , Packet Format
A1. For "If the normal IP return path is deemed = unreliable=20 ,one may use "Reply
      via an IPV4/IPV6 UDP = Packet=20 with Router Alert " .
   
     Actually it was not = clear how=20 using such mode of reply will increase the chance to receive the=20
     reply packet . In some = external=20 presentation , it is explained as the reply will be routed  in a=20
     transient LSR by the = RP(instead of=20 the LC ) and as such the reply packet will be correctly =
     routed in = the case where=20 the FIB of the LC is corrupted . May be it worth to document this=20
     explanation into the draft=20
 
    What about "Reply and log " , in = this case=20 the operator could check the remote end to see if any
     log in case of no reply = received .=20 For sacalability , The receiving station count the nbr of echo=20
     request for = each  (Source IP Address,Source UDP port , Sender Handle). =
    and/or "Reply Via NMS" =  ,path=20 from any node to NMS is the most
     watched path (from OPS = perspective)=20 and we could assume it is up
     (otherwise it is currently = under=20 attention of the operator ) . In this mode the node
    encapsulate the reply in IP-in-IP = through=20 the NMS .
 
A2.For "TLVs may be nested within other TLV ......"=20
     The above indicate that we = could=20 liberally nest TLV within TLV , but actually it is not the case =
     We do have strict TLV and = SUB-TLV=20 as the "Type" field of the TLV and SUB-TLV do Overlap . =  
     In other word : TLV could = not appear=20 inside another TLV . SUB-TLV could not appear unless inside =
     TLV .
      
A3. For Target-FEC-Stack TLV contain 1) Sub-TLV LDP = IPv4 and=20 2)Sub-TLV VPN IPV4 Prefix
      the length could be = :  i)=20 24  or  j) 20 ?   
     For 24 , = each SUB-TLV is=20 aligned to four-octet-boundary .
     For 20 , the TLV ( as = a whole)=20 is aligned to four-octet-boundary
 
     If the draft recommend = the way=20 to align each sub-TLV to four-octet-boundary(length =3D = 24) ,but in=20
     such case why = the=20 length value of the SUB-TLV was chosen not to include the padding = byte ??=20
     ex: For LDP IPv4 the length = is=20 5 instead of 8 . The "length" field = should specify=20 the actual size
      (in this case 8) used = on the=20 wire , the receiving node from the "Type" field = could=20 determine that
     the used part is just 5 .=20  
     Else (length =3D 20) =  , could we=20 modify the example to include more than one Sub-TLV to make the =
     case clearer .
 
A4. For the Para (page 10)  "Types less than = 32768=20 ...etc " .
      may be changing = the word=20 "mandatory" to "mandatory supported " .
 
      For the Para (page = 10) =20 "Types greater than .....etc " .
       may be = changing the=20 word "optional " to "optionally=20 supported"        
 
     This  will make it = more clear=20 that "mandatory" and "optional" refer to the support of the node for=20
     such  TLV's=20 and not the existence of such TLV in the = packet=20
        
 A5. Section 3.2 page 12 .
       for the = Sub-TLV=20 "RSVP IPv4 Session Query" , better to be named as just "RSVP IPv4 = Session"=20  
       same for IPv6=20
 
A6. Page 12 , the Para  "say LSR X wanted = ..etc ".=20
      is this applicable to = "LSP=20 Trace" also ???
      For the case = where RSVP=20 Tunnel end at the destination PE (Target FEC TLV could contain RSVP IPV4 =
     session Sub-TLVand IP VPN Prefix Sub-TLV. or Target FEC could contain just the = IP VPN=20 Prefix Sub-TLV ) ,
     is it workable for "LSP = Trace".=20    
      (The point that = in case=20 the target FEC contain just the IP VPN Sub-TLV , the transient LSR will=20 find no  
      Sub-TLV FEC which = correspond=20 to the RSVP LSP or the LDP LSP so how = this=20 LSR could check  )  .
 
      The confusing point = that a=20 transient LSR in some cases is able to check the received label against = the=20
      target FEC ,and in=20 other cases it is not possible . Is it = correct ??=20
      If yes : How the = transient LSR=20 could differentiate .
  
      N.B: may be the = answer to above=20 is within section 4.4 (Receiving an MPLS echo request) ,but i am = having=20
          &nbs= p; =20 difficulty to understand section 4.4=20    
 
A7. NIL FEC
      One usage for "NIL = FEC" is=20 documented in section 4.2 . Any other usage not documented in the draft=20 ???
 
Brgds
------=_NextPart_000_01B5_01C54F22.73022550-- --===============0569532295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0569532295==-- From mpls-bounces@lists.ietf.org Mon May 02 06:19:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSY12-0002qa-V4; Mon, 02 May 2005 06:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSY10-0002q4-K7 for mpls@megatron.ietf.org; Mon, 02 May 2005 06:19:02 -0400 Received: from hotmail.com (bay21-dav18.bay21.hotmail.com [65.54.233.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23835 for ; Mon, 2 May 2005 06:18:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 May 2005 03:20:34 -0700 Message-ID: Received: from 57.250.229.136 by BAY21-DAV18.phx.gbl with DAV; Mon, 02 May 2005 10:20:34 +0000 X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. elk" To: Date: Mon, 2 May 2005 14:27:24 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 May 2005 10:20:34.0997 (UTC) FILETIME=[93E7E650:01C54F00] Cc: Subject: [mpls] Clarification reg LSP PING - Draft ver 08- Part 3/3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132878357==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0132878357== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01C54F23.0F2D3DC0" This is a multi-part message in MIME format. ------=_NextPart_000_01BF_01C54F23.0F2D3DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Part 3 of 3=20 Appreciate U clarification for below : =20 C. Page 29 , Theory of Operation=20 C1. Page 29 , In the Para "FEC stack can be more complex .........". For " The FEC stack would contain two sub-tlv's ,the first being a = VPN IPv4 prefix,and the second being=20 an LDP IPv4 prefix".=20 To follow the way the target FEC TLV is built also the convention = used in page 12 Para " say LSR X Wanted ....", the above sentence to be re-written as : "The FEC stack would contain two sub-TLV's,the first being an LDP = IPv4 prefix,and the second being=20 a VPN IPv4 prefix." C2. Page 29 , in the Para "When an MPLS echo .....". For " the receiver is expected to do a number of tests that verify = ...". could the draft elaborate on what are those tests . which are = applicable to the egress node and which are=20 applicable to a transient node . =20 This will help to understand/clarify the procedure in section 4.4 = "Receiving an MPLS Echo Request". =20 C3. Page 30 , in Para "to achieve some degree ..............". For " "Multipath Exercise" sub-TLV ".=20 no such sub-TLV in this ver of the draft , may be to replace with = : " Multipath field ,part of the downstream mapping TLV ". For "The Ingress can then send MPLS echo request that exercise = these paths". Could the draft elaborate how this is done .=20 C4. Page 30, in Para "To detect certain ......." For "will prevent a router from forwarding such packet out = unlabeled interfaces".=20 guess the router here is the PHP router and above could be = re-written as : " will prevent the PHP router from forwarding such packet out = unlabeled interface."=20 C5. Page 31 , Para "The sender chooses .....". For "However, a sender MAY choose to send a group of echo requests = with the same=20 sequence number to improve .............". Guess this is more relevant/practical in trace mode . and it could = be re-written as : "However , in trace mode a sender MAY choose to send a group of = echo requests ,having the same TTL=20 value, with the same sequence number to improve ..............."=20 C6.Page 31 .Section 4.4 "Receiving an MPLS Echo Request". =20 Beleieve despite almost 3.5 page ,this section is squeezed .=20 The Section list/state procedure/algorithm but not muh reg the = logic itself behind this procedure/algorithm.=20 As too many clarification requested in this section , they will be = sent in seperate msg . C7. Page 36 , section 4.6 "Receiving an MPLS Echo Reply".=20 Para " if the echo reply contains downstream mappings , and X = wishes to traceroute further ,...."=20 for " it should copy the downstream Mappings into its next Echo = Request (with TTL incremented=20 by one)." =20 Why "Downstream Mappings" have an "s" . node X should copy a = single DS mapping object in the Echo Request - the DS mapping object which correspond to the path = which X need to follow- .=20 D. Typing Error=20 D1. Page 31 , Para "An MPLS echo Request Must have .........". for " the echo request SHOULD a downstream mapping TLV".=20 "Have " is missing . D2. Page 9 , "The LDP IPv4 TLV has the following format : " Replace "TLV" with "Sub-TLV". D3. Page 9 , " A FEC TLV which contain just ......."=20 Replace "FEC" with "Target FEC Stack "=20 D4. Page 22 , "will serve to execise this path" .=20 missing "c". D5. Page 23 , "Null labels are explicitly inluded ..." missing "c". Brgds ------=_NextPart_000_01BF_01C54F23.0F2D3DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Part 3 of 3
Appreciate U clarification for below :
 
      
 
C. Page 29 , Theory of Operation
 
C1. Page 29 , In the Para "FEC stack can be = more complex=20 ........".
      For " The FEC stack = would=20 contain two sub-tlv's ,the first being a VPN IPv4 prefix,and the second = being=20
      an LDP IPv4 prefix".=20
 
     To follow the way the = target FEC TLV=20 is built also the convention used in page 12 Para " say LSR X Wanted=20 ...",
     the above=20 sentence to be re-written as :
      "The FEC stack =  would=20 contain two sub-TLV's,the first being an LDP IPv4 prefix,and the second = being=20
       a VPN IPv4=20 prefix."
 
 
C2. Page 29 , in the Para "When an MPLS echo=20 ....".
      For " the receiver is = expected=20 to do a number of tests that verify ....".
      could the draft = elaborate=20 on what are those tests . which are applicable to the egress node and = which are=20
      =20 applicable  to a = transient node .=20   
      This will help = to=20 understand/clarify  the procedure in section 4.4 "Receiving an MPLS = Echo=20 Request".  
 
C3. Page 30 , in Para "to achieve some degree=20 .............".
      For " "Multipath = Exercise"=20 sub-TLV ".
      no such sub-TLV = in this=20 ver of the draft , may be to replace with :
     " Multipath field ,part = of the=20 downstream mapping TLV  ".
 
     For "The Ingress can then = send MPLS=20 echo request that exercise these paths".
     Could the draft elaborate = how this is=20 done .
 
C4. Page 30, in Para "To detect certain = ......"
      For "will prevent a = router from=20 forwarding such packet out unlabeled interfaces".
      guess the router here = is the=20 PHP router and above could be re-written as :
      " will prevent the = PHP router=20 from forwarding such packet out unlabeled interface."
 
C5. Page 31 , Para "The sender chooses = ....".
      For "However, a = sender MAY=20 choose to send a group of echo requests with the same
       sequence number = to=20 improve .............".
      Guess this is more=20 relevant/practical in trace mode . and it could be re-written as = :
      "However , in trace = mode a=20 sender MAY choose to send a group of echo requests ,having the same TTL=20
      value, with the=20 same sequence number to improve=20 .............." 
 
C6.Page 31 .Section 4.4 "Receiving an MPLS Echo=20 Request".
       
      Beleieve despite = almost=20 3.5 page ,this section is squeezed .
      The Section = list/state=20 procedure/algorithm but not muh reg the logic itself behind this=20 procedure/algorithm.
      As too many = clarification=20 requested in this section , they will be sent in seperate msg=20
 
C7. Page 36 , section 4.6 "Receiving an MPLS Echo = Reply".=20
      Para " if the = echo reply=20 contains downstream mappings , and X wishes to traceroute further ,...." =
      for " = it should copy=20 the downstream Mappings into its next Echo Request (with TTL incremented =
      by=20 one)."  
      Why "Downstream = Mappings" have=20 an "s" . node X should copy a single DS mapping object in = the
       Echo Request - = the DS=20 mapping object which correspond to the path = which X=20 need to follow- .
 
 
D. Typing Error
 
D1. Page 31 , Para "An MPLS echo Request Must have=20 ........".
       for " the echo = request=20 SHOULD a downstream mapping TLV".
        "Have " = is missing=20
 
D2. Page 9 , "The LDP IPv4 TLV has the following = format :=20 "
       Replace "TLV" = with=20 "Sub-TLV".
 
D3. Page 9 , " A FEC TLV which contain just ......." =
       Replace "FEC" = with=20 "Target FEC Stack "
 
D4. Page 22 , "will serve to execise this path" .=20
      = missing=20 "c".
 
D5. Page 23 , "Null labels = are explicitly=20 inluded ..."
      missing=20 "c".
 
Brgds =  
------=_NextPart_000_01BF_01C54F23.0F2D3DC0-- --===============0132878357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0132878357==-- From mpls-bounces@lists.ietf.org Mon May 02 06:36:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYHl-0004Us-Lk; Mon, 02 May 2005 06:36:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYHj-0004EZ-8W for mpls@megatron.ietf.org; Mon, 02 May 2005 06:36:19 -0400 Received: from hotmail.com (bay21-dav18.bay21.hotmail.com [65.54.233.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27995 for ; Mon, 2 May 2005 06:36:15 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 May 2005 03:37:26 -0700 Message-ID: Received: from 57.250.229.136 by BAY21-DAV18.phx.gbl with DAV; Mon, 02 May 2005 10:37:25 +0000 X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. elk" To: Date: Mon, 2 May 2005 14:44:39 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 May 2005 10:37:26.0163 (UTC) FILETIME=[EE9B9630:01C54F02] Cc: Subject: [mpls] Clarification reg LSP PING - Draft ver 08- Part 2/3 - First particle X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0665691255==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0665691255== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0291_01C54F25.77FE83C0" This is a multi-part message in MIME format. ------=_NextPart_000_0291_01C54F25.77FE83C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable N.B: Sorry , have to partition part 2/3 further into First particle and = 2nd particle =20 Part 2 of 3 - First Particle =20 Appreiate the clarification : B. Downstream Mapping TLV , Page 20=20 B1 . For "Only one downstream mapping request may appear in am echo = request " change "downstream mapping request" to "downstream mapping = object" . =20 B2. For "Otherwise Downstream mapping objects should include a = downstream mapping object=20 ............could be forwarded" . The DS TLV do not include DS TLV . May be rewriting the above = as=20 "Otherwise ,the echo reply should include a downstream = mapping object .......could be forwarded". B3. Moving the "I" Flag to be global flag .=20 why : The Requirement is to know the Destination " interface = and label stack" object . Currently: U have to Trace the full path to get those info .=20 what is needed : Just using PING and requesting the = "Interface and label Stack" object to be=20 included in the echo reply . =20 B4. Multipath Type , Page 22=20 The Sending LSR have the following to influence the multipath :=20 i) The destination IP , which need to be chosen from the 127/8 = range .=20 and/or=20 ii) The Source UDP Port . =20 The Transient LSR (where the TTL expire) have the following info : i) the source IP ,Destination IP and the source UDP Port . ii) The received label Stack , say {Ln,Ln-1,....L1} iii) The Received DS Mapping TLV=20 Case 1- The "N" Flag set to indicate non-IP Packet=20 =20 Sub-case 1a- The LSR consider only the Received Label stack . Run = is Hash function (assuming avail of=20 more than one interface , say intfa and = intfb ) on the received label stack to find out on which=20 interface it will be forwarded , say Intf_a = The LSR reply with DS mapping TLV with intfa = details and with "Multipath type" =3D zero .=20 =20 Sub-Case 1b- The LSR consider the Received label Stack and the info = of the multipath type=20 (Multipath Type =3D 9 or Zero ) received . = For simplicity assume no info for the "Multipath Type"=20 i.e.: "Multipath Type" =3D Zero .=20 The LSR run his Hash and find 2 bit-masked = label set (say bit_masked_set_1 and bit_masked_set_2).=20 one which will forward the packet to intfa = and the other to intfb . The LSR reply by 2 DS mapping=20 TLV both with "MultiPath type" =3D 9 . But : = the only possible values for both set (Bit_masked_set_1 ,=20 Bit_masked_set_3) are the Explicit null = label or Router Alert label. is it correct ???=20 Say Bit_masked_set_1 resolve to Explicit = null , could it be used by the sending LSR more than once .=20 ex: = {Ln,Ln-1,Ln-2,......,Explicit_null,Explicit_null,L1} and still get = forwarded to intfa ???. =20 is it location independent ,ex: = {Ln,Explicit_Null,Ln-1,.......L1} same as = {Ln,Ln-1,Explicit_null,Ln-2,.....L1} , both will be forwarded to intfa ???. For Case 1 , Is it sub-case 1a or Sub-case 1b ??? .=20 Case 2 - The "N" Flag cleared to indicate IP Packet . Sub-Case 2a- The Transient LSR consider the following when = calculating the hash : i) The Source IP Address . ii) The Source UDP port . iii) The multipath info received ( Multipath = Type =3D Zero,or 2 or 4 or 8 ) =20 Sub-case 2b- The Transient LSR consider the following when = calculating the hash :=20 i) The Source IP Address . ii) The Source UDP port . iii) The multipath info received ( Multipath = Type =3D zero, or 2 or 4 or 8 ) =20 iv) the received label stack .=20 Sub-Case 2c- The Transient LSR consider the following when = calculating the hash :=20 i) The Source IP Address . ii) The Source UDP port . iii) The multipath info received ( Multipath = Type =3D zero, or 2 or 4 or 8 or 9 ) =20 iv) the received label stack .=20 which sub-case is valid ??? . B5. The Filed "Depth Limit" ,page 22=20 Guess this filed should be ignored (or set to zero) when the DS = mapping TLV is part of Echo request .=20 This field is populated by the LSR sending the echo reply to = indicate the number of labels out from=20 the received label stack considered in the hash . is it correct = ?.=20 if yes : consider=20 the Transient LSR received label stack {L3,L2,L1} and DS = Mapping TLV=20 The transient LSR reply with DS mapping TLV with label field = {L4,L2,L1} and Depth-limit=3D2=20 is it mean that LSR will do the hah over {L3,L2} or {L2,L1} or = even {L3,L1} ???=20 B6. Protocol , page 23=20 Consider PE1----P1----P2----PE2 . The PE1 send echo request with TTL=3D1 and DS mapping TLV.=20 The DS mapping TLV contain the 2 label , {(L1,LDP),(L2,IP VPN)} = =20 P1 send echo reply with DS mapping TLV .=20 The DS mapping TLV contain the 2 label as : i) {(L3,LDP),(L2,IP VPN)}=20 or ii) {(L3,LDP),(L2,Unknown)} =20 In the first case , P1 copy the protocol of L2 from the DS = mapping TLV received .=20 In the 2nd case ,P1 have no self info which protocol issued L2 = so it mark L2 with Unknown protocol=20 irrespective of what protocol was associated with L2 in the = received DS mapping TLV .=20 =20 so which case the draft is calling for ?? . B7. Multipath info encoding , page 23=20 B7.1 For the first Para "The multipath info encodes labels = ..........".=20 The sentence "The contents of the fields are shown in the = table above",=20 It seems the table is missing . =20 The sentence "Label and Address pairs .....", in this ver of = the draft the "multipath type" =3D 1 =3D label=20 is deprecated . Also , what it meant by "pairs" ??? .=20 B7.2 For "multipath type" =3D 8 or 9 encoding . could we have an = example to make it clear .=20 B7.3 For the Para " if the received multipath information is = ........". For the sentence " if the received multipath information is = non-null," , is it mean=20 "If their is DS mapping TLV received " ???. =20 =20 For " if the received multipath information is null" , is it = mean=20 " If their is no DS mapping TLV received " . For "The type must be set to 0" , is it Zero or 7 (no-match) = ?? Re-writing the Para as :=20 "If their is Downstream Mapping TLV received ,the labels and = IP address MUST be picked from=20 the set provided . if none of these labels or addresses map = to a particular downstream interface , then in the downstream mapping TLV for that interface in the = echo reply ,the multipath type must=20 be set to 7 (no match) . If their is no DS mapping TLV = received ,the receiver LSR simply return no=20 Downstream mapping TLV in the echo reply ". =20 B7.4 for the Para "For Example ,suppose ..........." . my understanding that the address should be in the 127/8 range = ???. =20 For " with Hash key Type 7 " , in this ver of the draft the = Hash key is renamed multipath Type .=20 Also , in this ver multipath-Type =3D 7 is not defined (only 0 = ,2,4,8 and 9 ).=20 =20 For " The Head end reflects ...." , could we elaborate in the = draft how this is done .guess this=20 will make it clearer for the reader .=20 An example of using label to exercise path ,will be very = useful .=20 B7.5 For the Para "Note that computing .....".=20 Could we have it as explicit notification(instead of implicit) = ,say by setting certain global flag in the=20 echo reply .=20 B7.6 For " If a packet was originated with TTL n>1 arrived with = outermost label L at LSR X ....".=20 Guess it could be more clear as : " If a packet was originated with TTL n>1 arrived with outermost = label L with TTL=3D1 at LSR X ..."=20 B7.7 For "Note that there are multiple downstream label fields in each = TLV as the incoming label L may be=20 swapped with a label stack ".=20 Consider PE1----P1---Tunnel1--P2---PE2=20 testing for IP VPN LSP using trace . Case 1 : PE1 send echo request with DS mapping TLV with label fields : = {(L1,LDP),(L2,IP VPN)} P1 reply include DS mapping TLV with label fields = {(L3,RSVP-TE),(L4,LDP),(L2,IP VPN)}. OR=20 Case 2 :=20 PE1 send echo request with DS mapping TLV with label fields : = {(L1,LDP)}=20 P1 reply include DS mapping TLV with label fields = {(L3,RSVP-TE),(L4,LDP)}. is it case 1 or 2 ??=20 The above note in the draft could be understood that it is = case 2 ??.=20 while the definition of "downstream label " in page 23 = ,indicate it is case 1 . =20 Brgds ------=_NextPart_000_0291_01C54F25.77FE83C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
N.B: Sorry , have to partition part 2/3 = further=20 into First particle and 2nd particle  
 
Part 2 of 3 - First Particle=20  
 
Appreiate the clarification = :
 
    B. Downstream Mapping TLV , Page 20
 
   B1 . For "Only one downstream mapping = request may=20 appear in am echo request  "
          chan= ge=20 "downstream mapping request" to "downstream mapping object" .=20  
 
    B2. For "Otherwise Downstream = mapping=20 objects should include a downstream mapping object
          &nbs= p;     =20  ............could be forwarded" .
          &nbs= p;The DS=20 TLV do not include DS TLV . May be rewriting the above as
          =20 "Otherwise ,the echo reply should include a downstream mapping = object =20 ......could be forwarded".
 
    B3. Moving the "I" = Flag  to be=20 global flag .
          =20 why : The Requirement is to know the Destination " interface and = label=20 stack" object .
          =20 Currently: U have to Trace the full path to get those info . =
          =20 what is needed : Just using PING and requesting the "Interface and label = Stack"=20 object to be
          &nbs= p;=20 included in the echo reply .=20        
 
   B4. Multipath Type , Page 22 =
 
        The = Sending LSR=20 have the following to influence the multipath : 
        i)=20 The destination IP , which need to be chosen from the 127/8 range . =
        and/or=20
       ii) The Source = UDP Port .=20       
 
     The Transient LSR (where = the TTL=20 expire) have the following info :
      i) the source IP = ,Destination=20 IP and the source UDP Port .
      ii) The received = label Stack ,=20 say {Ln,Ln-1,....L1}
     iii)  The Received DS = Mapping=20 TLV
 
     Case 1- The "N" Flag set to = indicate=20 non-IP Packet
    
     Sub-case 1a- The LSR = consider only=20 the Received Label stack . Run is Hash function (assuming avail of =
          &nbs= p;            = ;     =20 more than one interface , say intfa and intfb = ) on=20 the received label stack to find out on which
          &nbs= p;            = ;    =20 interface it will be forwarded , say Intf_a .
          &nbs= p;            = ;   =20 The LSR reply with DS mapping TLV with intfa details and with "Multipath = type" =3D=20 zero .
     
    Sub-Case 1b- The LSR consider the = Received=20 label Stack and the info of the multipath type
          &nbs= p;            = ;     =20 (Multipath Type =3D 9 or Zero )  received . = For=20 simplicity assume no info for the "Multipath Type"
          &nbs= p;            = ;     =20 i.e.: "Multipath Type" =3D Zero .
          &nbs= p;            = ;   =20 The LSR run his Hash and find 2 bit-masked label set (say = bit_masked_set_1 and=20 bit_masked_set_2).
          &nbs= p;            = ;   =20 one which will forward the packet to intfa = and the=20 other to intfb . The LSR reply by 2 DS mapping
          &nbs= p;            = ;    =20 TLV both with "MultiPath type" =3D 9 . But : = the only=20 possible values for both set (Bit_masked_set_1 , 
          &nbs= p;            = ;   =20  Bit_masked_set_3) are the Explicit null label or =20 Router Alert label. is it correct ???
          &nbs= p;            = ;   =20  Say Bit_masked_set_1 resolve to Explicit null , could it be used = by=20 the sending LSR more than once .
          &nbs= p;            = ;    =20 ex: {Ln,Ln-1,Ln-2,......,Explicit_null,Explicit_null,L1} and still get = forwarded=20 to intfa ???.   
          &nbs= p;            = ;     =20 is it location independent ,ex: {Ln,Explicit_Null,Ln-1,.......L1} same = as=20 {Ln,Ln-1,Explicit_null,Ln-2,.....L1} ,
          &nbs= p;            = ;      =20 both will be forwarded to intfa  ???.
 
    For Case 1 , Is it sub-case = 1a or=20 Sub-case 1b ???  .
 
    Case 2 - The "N" Flag cleared to = indicate=20 IP Packet .
 
    Sub-Case 2a- The Transient LSR = consider the=20 following when calculating the hash :
          &nbs= p;            = ;  =20 i) The Source IP Address .
          &nbs= p;            = ; =20 ii) The Source UDP port .
          &nbs= p;            = ; iii)=20 The multipath info received ( Multipath Type =3D Zero,or 2 or 4 or 8 )=20  
 
    Sub-case 2b- The Transient LSR = consider the=20 following when calculating the hash :
          &nbs= p;            = ;  =20 i) The Source IP Address .
          &nbs= p;            = ; =20 ii) The Source UDP port .
          &nbs= p;            = ; iii)=20 The multipath info received ( Multipath Type =3D zero, or 2 or 4 or 8 )=20  
          &nbs= p;            = ;=20 iv) the received label stack .
 
    Sub-Case 2c- The Transient LSR = consider the=20 following when calculating the hash :
          &nbs= p;            = ;  =20 i) The Source IP Address .
          &nbs= p;            = ; =20 ii) The Source UDP port .
          &nbs= p;            = ; iii)=20 The multipath info received ( Multipath Type =3D zero, or 2 or 4 or 8 or = 9 )=20  
          &nbs= p;            = ;=20 iv) the received label stack .
 
    which sub-case is valid ???=20
 
  B5. The Filed "Depth Limit" ,page 22 =
         = Guess this=20 filed should be ignored (or set to zero) when the DS mapping TLV is part = of Echo=20 request .
         = This field is=20 populated by the LSR sending the echo reply to indicate the number of = labels out=20 from
         the = received=20 label stack considered in the hash . is it = correct ?.=20
         if = yes :=20 consider
         the = Transient=20 LSR received label stack {L3,L2,L1} and DS Mapping TLV
         The = transient=20 LSR reply with DS mapping TLV with label field {L4,L2,L1} and = Depth-limit=3D2=20
         is = it mean=20 that LSR will do the hah over {L3,L2} or {L2,L1} or even {L3,L1}=20 ??? 
 
  B6. Protocol , page 23
        = Consider =20 PE1----P1----P2----PE2 .
        The PE1 = send echo=20 request with TTL=3D1 and DS mapping TLV.
         The = DS=20 mapping TLV contain the 2 label , {(L1,LDP),(L2,IP VPN)} . =
         P1 send=20 echo reply with DS mapping TLV .
         The DS=20 mapping TLV contain the 2 label as :
         i)=20 {(L3,LDP),(L2,IP VPN)} 
        =20 or
         ii) = {(L3,LDP),(L2,Unknown)}   
 
        In the = first case ,=20 P1 copy the protocol of L2 from the DS mapping TLV received . =
        In the = 2nd case ,P1=20 have no self info which protocol issued L2 so it mark L2 with Unknown = protocol=20
       =20 irrespective of what protocol was associated = with L2 in=20 the received DS mapping TLV .
        =
        so which = case the=20 draft is calling for ?? .
 
   B7. Multipath info encoding , page 23=20
 
    B7.1 For the first Para  = "The=20 multipath info encodes labels ...........".
          &nbs= p; The=20 sentence "The contents of the fields are shown in the table above",=20
          &nbs= p; It=20 seems the table is missing .  
          &nbs= p; The=20 sentence "Label and Address pairs .....", in this ver of the draft the=20 "multipath type" =3D 1 =3D label
          &nbs= p; is=20 deprecated . Also , what it meant by "pairs" ??? . =
 
   B7.2 For "multipath type" =3D 8 or 9 = encoding .=20 could we have an example to make it clear .
 
   B7.3  For the Para " if the = received=20 multipath information is .........".
          &nbs= p; For=20 the sentence "  if the received multipath information is = non-null," ,=20 is it mean 
          &nbs= p; "If=20 their is DS mapping TLV received " ???.  
          &nbs= p; 
          &nbs= p; For "=20 if the received multipath information is null" , is it mean =
          &nbs= p; " If=20 their is no DS mapping TLV received  " .
 
          =20 For "The type must be set to 0" , is it Zero or 7 (no-match) = ??
 
          &nbs= p;Re-writing=20 the Para as :
 
          =20 "If their is Downstream Mapping TLV received ,the labels and IP address = MUST be=20 picked from
          &nbs= p; the=20 set provided . = if none of=20 these labels or addresses map to a particular downstream interface=20 ,
          &nbs= p; then=20 in the downstream mapping TLV for=20 that interface in the echo reply ,the multipath type must
          &nbs= p; be set=20 to 7 (no match) . If their is no DS mapping = TLV=20 received ,the receiver LSR simply return no
          =20 Downstream mapping TLV in the echo reply=20 ".
 
          &nbs= p;  =20
  B7.4 for the Para  "For Example = ,suppose=20 .........." .
          my=20 understanding that the address should be in the 127/8 range = ???.
         =20
          =20 For " with Hash key Type 7 " , in this ver of the draft the Hash key is = renamed=20 multipath Type .
          Also ,=20 in this ver multipath-Type =3D 7 is not defined (only 0 ,2,4,8 and 9 ).=20
          &nbs= p;
          =20 For " The Head end reflects ...." , could we elaborate in = the=20 draft how this is done  .guess this
          =20 will make it clearer  for the reader .
 
          An=20 example of using label to exercise path ,will be very useful . =
 
 B7.5 For the Para "Note that computing .....". =
         = Could we have=20 it as explicit notification(instead of implicit)  ,say by setting = certain=20 global flag in the
         = echo reply .=20
 
 B7.6 For " If a packet was originated with TTL = n>1=20 arrived with outermost label L at LSR X ....".
          &nbs= p; Guess=20 it could be more clear as :
        " If a = packet was=20 originated with TTL n>1 arrived with outermost label L with TTL=3D1 = at LSR X=20 .."
 
 B7.7 For "Note that there are multiple = downstream label=20 fields in each TLV as the incoming label L may be
          &nbs= p;       =20 swapped with a  label stack ".
 
         = Consider=20 PE1----P1---Tunnel1--P2---PE2
          testing=20 for IP VPN LSP using trace .
          Case 1=20 :
          PE1=20 send echo request with DS mapping TLV with label fields : =  {(L1,LDP),(L2,IP=20 VPN)}
          P1=20 reply include DS mapping TLV with label fields=20 {(L3,RSVP-TE),(L4,LDP),(L2,IP VPN)}.
 
         OR=20
         = Case 2 :=20
         PE1 = send echo=20 request with DS mapping TLV with label fields :  {(L1,LDP)}
          P1=20 reply include DS mapping TLV with label fields=20 {(L3,RSVP-TE),(L4,LDP)}.
 
          is it=20 case 1 or 2 ??
          The=20 above note in the draft could be understood that it is case 2 ??.=20
          whil= e the=20 definition of "downstream label " in page 23 ,indicate it is = case 1 .=20  
 
 
 Brgds=20
------=_NextPart_000_0291_01C54F25.77FE83C0-- --===============0665691255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0665691255==-- From mpls-bounces@lists.ietf.org Mon May 02 06:38:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYKF-0001od-HG; Mon, 02 May 2005 06:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYKD-0001ja-S2 for mpls@megatron.ietf.org; Mon, 02 May 2005 06:38:53 -0400 Received: from hotmail.com (bay21-dav17.bay21.hotmail.com [65.54.233.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28780 for ; Mon, 2 May 2005 06:38:51 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 May 2005 03:38:23 -0700 Message-ID: Received: from 57.250.229.136 by BAY21-DAV17.phx.gbl with DAV; Mon, 02 May 2005 10:38:23 +0000 X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. elk" To: Date: Mon, 2 May 2005 14:47:14 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 May 2005 10:38:23.0359 (UTC) FILETIME=[10B300F0:01C54F03] Cc: Subject: [mpls] Clarification reg LSP PING - Draft ver 08- Part 2/3 - 2nd particle X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1512635305==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1512635305== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A4_01C54F25.D48E5890" This is a multi-part message in MIME format. ------=_NextPart_000_02A4_01C54F25.D48E5890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable N.B: Sorry , have to partition part 2/3 further into First particle and = 2nd particle =20 Part 2 of 3 - 2nd Particle =20 Appreiate the clarification : =20 B7.8 Page 25 . For the Para "The case where X is the ......." , and the = Para "the set of downstream router " . Guess by swapping the position of the 2 Para the sequence of = info will be more clearer .=20 B7.9 Page 25 . In the Para " The set of downstream routers ....." . for " The "No of multipaths" is the number of IP address/Next = label fields".=20 could U pls explain ???. B7.10 . The case of RSVP-TE Tunnel=20 consider :=20 PE1--P1--P2--P3---P4--P5--PE2=20 we do have RSVP-TE tunnel from P1 to P4 .=20 testing for IPv4 VPN =20 =20 PE1 will send Echo Request with DS mapping TLV contain the = label field=20 {(L1,LDP),(L2,IP VPN)} case 1 : The RSV-TE Tunnel is Pipe or Short-Pipe=20 P1 will reply with echo reply with DS mapping = TLV contain the label field=20 {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP = address is P4 router_id , the DS interface=20 is the Tunnel tail-end which is normally P4 = router_ID. From this info PE1 will know that his traffic = will be encapsulated into a Tunnel which start from=20 P1 .=20 believe is beneficiary if the reply from P1 = could also include the following info : i) That the Tunnel is Pipe or Short-Pipe mode=20 ii) The Tunnel ID .=20 For both , it is satisfied by a Tunnel object = (same as specified in draft-ietf-ccamp-tunproto-01).=20 PE1 now have full info , it is known that = traffic will be encapsulated in an RSVP tunnel which=20 start at P1 and end at P4 .also the Tunnel ID is = known .=20 Case2 : The RSVP-TE Tunnel is Uniform mode . P1 will reply with echo reply with DS mapping TLV = contain the label field=20 {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP = address is P2 router_id , the DS interface=20 is P2 interface connecting to P1 . From this info PE1 will know that his traffic = will be encapsulated into a Tunnel which start from=20 P1 .=20 believe is beneficiary if the reply from P1 = could also include the following info : i) That the Tunnel is Uniform mode .=20 ii) The Tunnel ID .=20 iii) the incremental step in TTL if chosen to = skip the tunnel transient node=20 "i" and "ii" same as case 1 . for "iii" ,P1 = will reply with "3" . In other word ,if PE1 need to skip=20 the tunnel just add 3 to the TTL used to reach = P1 . Any "Unused" bit's in the Tunnel object could=20 satisfy this requirement. PE1 now have full info , it is known that = traffic will be encapsulated in an RSVP tunnel which=20 start at P1 and end at P4 .also the Tunnel ID is = known . PE1 could decide to include the tunnel in=20 the trace (continue to increment the TTL by 1 ) = or to skip it (add 3 to the TTL used to reach P1). =20 B8. Page 26 , "Interface and Label Stack" object =20 =20 B8.1 This TLV considered to be optional TLV . could we state that = if the "Return code" field is non-zero,=20 this TLV should be included mandatory in the echo reply = =20 or at least , for all error code where the is = included/populated it is mandatory to include this=20 TLV in the echo reply. =20 B8.2 In "IPv4 Interface and label Stack" Object =20 For " If the Address type is "No Address", ..." .=20 the format of this TLV do not contain any field as "Address = type" ??=20 or this ref to the field of "Address Type" in the received = Downstream mapping TLV ?? If yes : The "Address Type" field in the received DS TLV = can not have the value "NO Address" , i.e.: "No-Address" is not a defined value . = ???.=20 B7.11 Consider the following : PE1--------P2=20 PE1 is trace testing for LDP IPv4 . Out from P2 , it do exist = qty 2 ECMP , one of those path the mpls forwarding is disabled . PE1 send Echo request with DS Mapping contain label field = {(L1,LDP)}. P1 will send Echo rely with "Return code"=3D 9 and = =3D1 , in addition : P1 will include (as normal) 2 DS mapping TLV .=20 The first one (where Mpls is enabled ) contain label field = ((L2,LDP). The 2nd one (where Mpls is disabled) contain no label field . PE1 , will be able to conclude that the "return code" is = applicable to the 2nd interface .=20 =20 Is the above is correct implementation . =20 Brgds ------=_NextPart_000_02A4_01C54F25.D48E5890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

N.B: Sorry , have to partition part 2/3 = further=20 into First particle and 2nd particle  
 
Part 2 of 3 - 2nd Particle=20  
 
 
Appreiate the clarification = :
 
   
 B7.8 Page 25 . For the Para "The case where X = is the=20 ......" , and the Para "the set of downstream router " .
         = Guess by=20 swapping the position of the 2 Para the sequence of info will be more = clearer .=20
 
 B7.9 Page 25 . In the Para " The set of = downstream=20 routers ....." .
         for "=20 The "No of multipaths" is the number of IP address/Next label fields".=20
         could U=20 pls explain ???.
 
B7.10 . The case of RSVP-TE Tunnel
          &nbs= p;=20 consider :
 
          &nbs= p; =20 PE1--P1--P2--P3---P4--P5--PE2
           we do have RSVP-TE tunnel from P1 to P4 .=20
          &nbs= p;   testing=20 for IPv4 VPN  
        =
          &nbs= p; =20 PE1 will send Echo Request with DS mapping TLV contain the label field=20
          &nbs= p; =20 {(L1,LDP),(L2,IP VPN)}
 
          &nbs= p; =20 case 1 : The RSV-TE Tunnel is Pipe or Short-Pipe
          &nbs= p;            = ;   =20 P1 will reply with echo reply with DS mapping TLV contain the label = field=20
          &nbs= p;            = ;  =20 {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP address is P4 router_id , = the DS=20 interface
          &nbs= p;            = ;  =20 is the Tunnel tail-end which is normally P4 router_ID.
          &nbs= p;            = ;  =20 >From this info PE1 will know that his traffic will be encapsulated into = a Tunnel=20 which start from
          &nbs= p;            = ;  =20 P1  .
          &nbs= p;            = ;  =20 believe is beneficiary if the reply from P1 could also include the = following=20 info :
          &nbs= p;            = ;  =20 i) That the Tunnel is Pipe or Short-Pipe mode
          &nbs= p;            = ; =20 ii) The Tunnel ID .
 
          &nbs= p;            = ; =20 For both  , it is satisfied by a Tunnel object (same as specified=20 in draft-ietf-ccamp-tunproto-01). =
 
          &nbs= p;            = ;=20 PE1 now have full info , it is known that traffic will be encapsulated = in an=20 RSVP tunnel which
          &nbs= p;            = ;=20 start at P1 and end at P4 .also the Tunnel ID is known .
 
 
       Case2 : = The RSVP-TE=20 Tunnel is Uniform mode .
          &nbs= p;         =20 P1 will reply with echo reply with DS mapping TLV contain the label = field=20
          &nbs= p;            = ;  =20 {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP address is P2 router_id , = the DS=20 interface
          &nbs= p;            = ;  =20 is P2 interface connecting to P1 .
          &nbs= p;            = ;  =20 >From this info PE1 will know that his traffic will be encapsulated into = a Tunnel=20 which start from
          &nbs= p;            = ;  =20 P1  .
          &nbs= p;            = ;  =20 believe is beneficiary if the reply from P1 could also include the = following=20 info :
          &nbs= p;            = ;  =20 i) That the Tunnel is Uniform mode .
          &nbs= p;            = ; =20 ii) The Tunnel ID .
           &n= bsp;           =20 iii) the incremental step in TTL if chosen to skip the tunnel transient = node=20
 
          &nbs= p;            = ; =20 "i" and "ii" same as case 1 . for "iii" ,P1 will reply with "3" . = In other=20 word ,if PE1 need to skip
          &nbs= p;            = ;=20 the tunnel just add 3 to the TTL used to reach P1 . Any = "Unused"=20 bit's in the Tunnel object could
           &n= bsp;           &nb= sp;=20 satisfy this requirement.
          &nbs= p;            = ;=20 PE1 now have full info , it is known that traffic will be encapsulated = in an=20 RSVP tunnel which
          &nbs= p;            = ;=20 start at P1 and end at P4 .also the Tunnel ID is known . PE1 could = decide to=20 include the tunnel in
          &nbs= p;            = ;=20 the trace (continue to increment the TTL by 1 ) or to skip it (add 3 to = the TTL=20 used to reach P1).
  
 
 B8. Page 26 , "Interface and Label Stack" = object=20  
         =20  
      B8.1 This TLV = considered to be=20 optional TLV . could we state that if the "Return code" field is = non-zero,=20
          &nbs= p;    =20 this TLV should be included mandatory in the = echo reply=20
          &nbs= p;   or=20 at least , for all error code where the <RSC> is = included/populated=20  it is mandatory to include this
          &nbs= p;   =20 TLV in the echo reply.  
 
     B8.2 In  "IPv4 = Interface and=20 label Stack" Object  
          &nbs= p; =20 For " If the Address type is "No Address", ..." .
          &nbs= p; =20 the format of this TLV do not contain any field as "Address type" ??=20
          &nbs= p; =20 or this ref to the field of "Address Type" in the received Downstream = mapping=20 TLV ??
          &nbs= p;  If=20 yes : The "Address Type" field in the received DS TLV can not have the = value "NO=20 Address" ,
          &nbs= p;            = ; i.e.:=20 "No-Address" is not a defined value .  ???. 
 
B7.11 Consider the following :
 
         =20 PE1--------P2
 
          =20 PE1 is trace testing for LDP IPv4 . Out from P2 , it do exist qty 2 ECMP = , one=20 of those path the mpls forwarding is disabled .
          =20 PE1 send Echo request with DS Mapping contain label field=20 {(L1,LDP)}.
          =20 P1 will send  Echo rely with "Return code"=3D 9  and = <RSC>=3D1 , in=20 addition :
          =20 P1 will include (as normal) 2 DS mapping TLV .
          =20 The first one (where Mpls is enabled ) contain label field=20 ((L2,LDP).
          =20 The 2nd one (where Mpls is disabled) contain no label field =
 
          &nbs= p;PE1 =20 , will be able to conclude that the "return code" is applicable to = the 2nd=20 interface .
        =20
          Is the=20 above is correct implementation .   
 
Brgds
------=_NextPart_000_02A4_01C54F25.D48E5890-- --===============1512635305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1512635305==-- From mpls-bounces@lists.ietf.org Wed May 04 07:35:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTIAM-0007Pd-Ap; Wed, 04 May 2005 07:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTIAK-0007PY-FX for mpls@megatron.ietf.org; Wed, 04 May 2005 07:35:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22716 for ; Wed, 4 May 2005 07:35:43 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTIOO-0002fo-Fp for mpls@ietf.org; Wed, 04 May 2005 07:50:17 -0400 Received: from du-069-0161.access.clara.net ([217.158.132.161] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DTIA6-000AeM-8L; Wed, 04 May 2005 12:35:32 +0100 Message-ID: <09b201c5509d$a8951fc0$1c849ed9@Puppy> From: "Adrian Farrel" To: , References: <4413.208.246.215.5.1114045137.squirrel@webmail.futsoft.com> Subject: Re: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout Date: Wed, 4 May 2005 11:14:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: psampath@avici.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Good morning Prabakaran, Your issue hangs on the word "if". In 3479 the interpretation of the FT Reconnection Timeout you quote says "if the S bit or C bit is set". These bits are only relevant to the procedures in 3479. The L bit indicates the choice between 3478 and 3479. In section 8.2 of 3479 you will find... It is not valid for both the L and either the S or C bits to be set to 1. Thus, there is no conflict (only peace and harmony) between the RFCs. If you want to compare and contrast the two approaches you may look at RFC 3612. As to which is more prevalent in "the industry", I will let the industry comment. I hope that clarifies. Regards, Adrian ----- Original Message ----- From: To: Cc: Sent: Thursday, April 21, 2005 1:58 AM Subject: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout > Dear MPLS-WG, > > I have the following doubts in MPLS LDP Graceful restart : > > I was searching in the mailing list about this topic, but, I am not able > to find out the relevant info, If this question has been already raised > and discussed in MPLS-WG, I would greatly appreciate if you could show the > pointers. > > 1. In RFC 3479 states, In section 8.2. FT Session TLV, > > " FT Reconnection Timeout > If the S bit or C bit in the FT Flags field is set, this indicates > the period of time the sending LSR will preserve state and > resources for FT Labels exchanged on the previous instantiation of > an FT LDP session that has recently failed. The timeout is > encoded as a 32-bit unsigned integer number of milliseconds. > > A value of zero in this field means that the sending LSR will > preserve state and resources indefinitely. " > > > 2. In RFC 3478 states, In section 2, > > "Setting the FT Reconnect Timeout to 0 indicates that the sender of > the TLV will not preserve its forwarding state across the restart, > yet the sender supports the procedures, defined in Section 3.3, > "Restart of LDP communication with a neighbor LSR" of this document, > and therefore could take advantage if its neighbor to preserve its > forwarding state across the restart." > > Question: > ========= > In the above point 1, as per RFC 3479, "a value of zero in the FT > Reconnect timeout means that the sending LSR will preserve state and > resrouces indefinitely" and as in point 2, as per RFC 3478, "if FT > Reconnect Timeout is zero, then the sender of the TLV will not preserve > its forwarding state across the restart" > > To me both the RFC 3478 and RFC 3479 conflicts with each other in the > above statements, I would like to know which one is appropriate for the > LDP graceful restart and what is the industry prefered one and is there > anything finalysed in the mailing list/MPLS-WG about this, authors please > clarify me regarding this? > > Thanks in advance, > Best regards, > Prabakaran T.S. > Future Communications Software, > a Flextronics company. > > > > > ************************************************************************** * > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > ************************************************************************** * > > > _______________________________________________ > 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 From mpls-bounces@lists.ietf.org Wed May 04 11:39:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLyd-0003CJ-Vg; Wed, 04 May 2005 11:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLyc-0003CE-3G for mpls@megatron.ietf.org; Wed, 04 May 2005 11:39:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22232 for ; Wed, 4 May 2005 11:39:51 -0400 (EDT) From: prabakarts@future.futsoft.com Received: from [202.56.251.200] (helo=mail.future.futsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMCi-00022T-4V for mpls@ietf.org; Wed, 04 May 2005 11:54:29 -0400 Received: from kailash.future.futsoft.com (unverified [10.203.112.3]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Wed, 4 May 2005 21:00:02 +0530 Received: from webmail.future.futsoft.com (webmail.future.futsoft.com [10.203.112.133]) by kailash.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j44FS27K018298; Wed, 4 May 2005 20:58:02 +0530 Received: from webmail.future.futsoft.com (localhost.localdomain [127.0.0.1]) by webmail.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j44FRdrg032617; Wed, 4 May 2005 20:57:39 +0530 Received: (from apache@localhost) by webmail.future.futsoft.com (8.12.8/8.12.8/Submit) id j44FRcYW032615; Wed, 4 May 2005 20:57:38 +0530 X-Authentication-Warning: webmail.future.futsoft.com: apache set sender to prabakarts@future.futsoft.com using -f Received: from 208.246.215.5 (SquirrelMail authenticated user prabakarts) by webmail.futsoft.com with HTTP; Wed, 4 May 2005 20:57:38 +0530 (IST) Message-ID: <3778.208.246.215.5.1115220458.squirrel@webmail.futsoft.com> In-Reply-To: <09b201c5509d$a8951fc0$1c849ed9@Puppy> References: <4413.208.246.215.5.1114045137.squirrel@webmail.futsoft.com> <09b201c5509d$a8951fc0$1c849ed9@Puppy> Date: Wed, 4 May 2005 20:57:38 +0530 (IST) Subject: Re: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout To: "Adrian Farrel" User-Agent: SquirrelMail/1.4.2-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.3 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 8bit Cc: psampath@avici.com, mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Thanks for the reply and appreciate for the good clarification Adrian. Now I am clarified well. Best regards, Prabakaran T.S. > Good morning Prabakaran, > > Your issue hangs on the word "if". > > In 3479 the interpretation of the FT Reconnection Timeout you quote says > "if the S bit or C bit is set". These bits are only relevant to the > procedures in 3479. > > The L bit indicates the choice between 3478 and 3479. > > In section 8.2 of 3479 you will find... > > It is not valid for both the L and either the S or C bits to be > set to 1. > > Thus, there is no conflict (only peace and harmony) between the RFCs. > > If you want to compare and contrast the two approaches you may look at RFC > 3612. > As to which is more prevalent in "the industry", I will let the industry > comment. > > I hope that clarifies. > Regards, > Adrian > > ----- Original Message ----- > From: > To: > Cc: > Sent: Thursday, April 21, 2005 1:58 AM > Subject: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout > > >> Dear MPLS-WG, >> >> I have the following doubts in MPLS LDP Graceful restart : >> >> I was searching in the mailing list about this topic, but, I am not able >> to find out the relevant info, If this question has been already raised >> and discussed in MPLS-WG, I would greatly appreciate if you could show > the >> pointers. >> >> 1. In RFC 3479 states, In section 8.2. FT Session TLV, >> >> " FT Reconnection Timeout >> If the S bit or C bit in the FT Flags field is set, this indicates >> the period of time the sending LSR will preserve state and >> resources for FT Labels exchanged on the previous instantiation of >> an FT LDP session that has recently failed. The timeout is >> encoded as a 32-bit unsigned integer number of milliseconds. >> >> A value of zero in this field means that the sending LSR will >> preserve state and resources indefinitely. " >> >> >> 2. In RFC 3478 states, In section 2, >> >> "Setting the FT Reconnect Timeout to 0 indicates that the sender of >> the TLV will not preserve its forwarding state across the restart, >> yet the sender supports the procedures, defined in Section 3.3, >> "Restart of LDP communication with a neighbor LSR" of this document, >> and therefore could take advantage if its neighbor to preserve its >> forwarding state across the restart." >> >> Question: >> ========= >> In the above point 1, as per RFC 3479, "a value of zero in the FT >> Reconnect timeout means that the sending LSR will preserve state and >> resrouces indefinitely" and as in point 2, as per RFC 3478, "if FT >> Reconnect Timeout is zero, then the sender of the TLV will not preserve >> its forwarding state across the restart" >> >> To me both the RFC 3478 and RFC 3479 conflicts with each other in the >> above statements, I would like to know which one is appropriate for the >> LDP graceful restart and what is the industry prefered one and is there >> anything finalysed in the mailing list/MPLS-WG about this, authors > please >> clarify me regarding this? >> >> Thanks in advance, >> Best regards, >> Prabakaran T.S. >> Future Communications Software, >> a Flextronics company. >> >> >> >> >> > ************************************************************************** > * >> This message is proprietary to Future Software Limited (FSL) >> and is intended solely for the use of the individual to whom it >> is addressed. It may contain privileged or confidential information >> and should not be circulated or used for any purpose other than for >> what it is intended. >> >> If you have received this message in error, please notify the >> originator immediately. If you are not the intended recipient, >> you are notified that you are strictly prohibited from using, >> copying, altering, or disclosing the contents of this message. >> FSL accepts no responsibility for loss or damage arising from >> the use of the information transmitted by this email including >> damage from virus. >> > ************************************************************************** > * >> >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls >> >> > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 05 09:26:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgMn-0002av-LE; Thu, 05 May 2005 09:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgMl-0002an-3C for mpls@megatron.ietf.org; Thu, 05 May 2005 09:26:11 -0400 Received: from smtp.apricot.ocn.ne.jp (apricot.ocn.ne.jp [222.146.40.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25198 for ; Thu, 5 May 2005 09:26:07 -0400 (EDT) Received: from barrister (i220-108-253-142.s02.a013.ap.plala.or.jp [220.108.253.142]) by smtp.apricot.ocn.ne.jp (Postfix) with SMTP id BA6AB66E8; Thu, 5 May 2005 22:26:06 +0900 (JST) Message-ID: <016601c55175$fba27a40$0301a8c0@barrister> From: "Seisho Yasukawa" To: "Loa Andersson" , "George Swallow" , Date: Thu, 5 May 2005 22:26:01 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: mpls@ietf.org Subject: [mpls] P2MP TE signaling requirements draft ready for WG last call X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2049365807==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2049365807== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C551C1.6B06E880" This is a multi-part message in MIME format. ------=_NextPart_000_0162_01C551C1.6B06E880 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, There is a new version of the P2MP TE signaling requirements draft. http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-02.txt Thanks everyone for contributing and helping the work. Now we think all of issues have been resolved and the draft is very stable. We believe that the draft is now ready for WG last call and this meets the timeline set out by the chairs in last Minneapolis meeting. Best regards, Seisho ------=_NextPart_000_0162_01C551C1.6B06E880 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi,
 
There is a new version of the = P2MP TE=20 signaling requirements draft.
 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-= sig-requirement-02.txt
 
Thanks everyone for = contributing and=20 helping the work.
Now we think all of issues = have been=20 resolved and the draft is very stable.
 
We believe that the draft is = now ready for=20 WG last call and
this meets the timeline set = out by the=20 chairs in last Minneapolis meeting.
 
Best regards,
Seisho
 
 
 
 
------=_NextPart_000_0162_01C551C1.6B06E880-- --===============2049365807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============2049365807==-- From mpls-bounces@lists.ietf.org Thu May 05 09:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgMq-0002bT-Ex; Thu, 05 May 2005 09:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgMo-0002bJ-4l for mpls@megatron.ietf.org; Thu, 05 May 2005 09:26:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25206 for ; Thu, 5 May 2005 09:26:11 -0400 (EDT) Received: from apricot.ocn.ne.jp ([222.146.40.101] helo=smtp.apricot.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTgb3-0001yb-JI for mpls@ietf.org; Thu, 05 May 2005 09:41:01 -0400 Received: from barrister (i220-108-253-142.s02.a013.ap.plala.or.jp [220.108.253.142]) by smtp.apricot.ocn.ne.jp (Postfix) with SMTP id BA6AB66E8; Thu, 5 May 2005 22:26:06 +0900 (JST) Message-ID: <016601c55175$fba27a40$0301a8c0@barrister> From: "Seisho Yasukawa" To: "Loa Andersson" , "George Swallow" , Date: Thu, 5 May 2005 22:26:01 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mpls@ietf.org Subject: [mpls] P2MP TE signaling requirements draft ready for WG last call X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644265140==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1644265140== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C551C1.6B06E880" This is a multi-part message in MIME format. ------=_NextPart_000_0162_01C551C1.6B06E880 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, There is a new version of the P2MP TE signaling requirements draft. http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-02.txt Thanks everyone for contributing and helping the work. Now we think all of issues have been resolved and the draft is very stable. We believe that the draft is now ready for WG last call and this meets the timeline set out by the chairs in last Minneapolis meeting. Best regards, Seisho ------=_NextPart_000_0162_01C551C1.6B06E880 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi,
 
There is a new version of the = P2MP TE=20 signaling requirements draft.
 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-= sig-requirement-02.txt
 
Thanks everyone for = contributing and=20 helping the work.
Now we think all of issues = have been=20 resolved and the draft is very stable.
 
We believe that the draft is = now ready for=20 WG last call and
this meets the timeline set = out by the=20 chairs in last Minneapolis meeting.
 
Best regards,
Seisho
 
 
 
 
------=_NextPart_000_0162_01C551C1.6B06E880-- --===============1644265140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1644265140==-- From mpls-bounces@lists.ietf.org Mon May 09 13:01:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBd0-0001yJ-1K; Mon, 09 May 2005 13:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBcx-0001yB-KQ for mpls@megatron.ietf.org; Mon, 09 May 2005 13:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05512 for ; Mon, 9 May 2005 13:01:04 -0400 (EDT) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVBs3-0000FR-S0 for mpls@ietf.org; Mon, 09 May 2005 13:16:47 -0400 Received: bgslc11.burtongroup.com 63.99.125.13 from 216.151.229.254 216.151.229.254 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 09 May 2005 13:00:46 -0400 From: Irwin Lazar To: Message-ID: Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [mpls] MPLScon is next week X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321839266==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0321839266== Content-type: multipart/alternative; boundary="B_3198488446_662696" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3198488446_662696 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MPLScon is next week in NYC. If you are interested in attending please use the code =B3CPN7=B2 to take 20% off the published price. More info is at http://www.mplscon.com/ Irwin --B_3198488446_662696 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MPLScon is next week MPLSc= on is next week in NYC.  If you are interested in attending please use = the code “CPN7” to take 20% off the published price.

More info is at http://www.mplscon.com/

Irwin

 --B_3198488446_662696-- --===============0321839266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0321839266==-- From mpls-bounces@lists.ietf.org Tue May 10 06:32:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS2I-0002Vs-8f; Tue, 10 May 2005 06:32:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS2F-0002Vl-Sk for mpls@megatron.ietf.org; Tue, 10 May 2005 06:32:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05795 for ; Tue, 10 May 2005 06:32:17 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVSHX-0003qv-TG for mpls@ietf.org; Tue, 10 May 2005 06:48:08 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.43) id 1DVS1b-0005qc-2a; Tue, 10 May 2005 12:31:49 +0200 Message-ID: <42808CF3.1000504@pi.se> Date: Tue, 10 May 2005 12:29:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lasserre Subject: Re: [mpls] Re: Summary: mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt References: <4268CCD7.3040803@pi.se> <426D208A.7020603@cisco.com> <039a01c549d2$a59851b0$6501a8c0@IBMT41ML> In-Reply-To: <039a01c549d2$a59851b0$6501a8c0@IBMT41ML> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: 7bit Cc: L2VPN , mpls@ietf.org, Rick Wilder , Bill Fenner , Mark Townsley , Margaret Wasserman , Vach Kompella X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Marc, inline please. Marc Lasserre wrote: > Besides agreeing with Luca's comments, I'd like to add that the > VPLS-LDP draft specifies how to reduce the size of the T-LDP full > mesh through hierarchical constructs in order to prevent scalability > problems with a large number of LDP adjacencies. Existing > deployments have demonstrated that large full mesh designs have > not caused scalabilty problems. Luca suggested that we try to substantiate this concern, I've suggested that we try to do so through some testing site. I would be open to discuss options. > > As far as MAC withdrawal is concerned, it is only used when a > primary AC fails, specifically in the case of dual-homed MTUs. Hence, > I do not see why LDP convergence time should be impacted. Re-reading the draft actually made me even more confused. Do you say that the MAC TLV is used only in one message? If so this should clearly be stated in the draft, if not we would need a list of the message in which the MAC TLV could appear. The message the you explictly say that the MAC TLV could go into is "MAC Address Withdraw Message". I would also prefer if we used the LDP terminology consistently, adding a new TLV won't change the name of an LDP message, I assume that a a "MAC Address Withdraw Message" is just an "Address Withdraw Message"? It is also said that: " The LDP Address Withdraw Message contains a FEC TLV (to identify the VPLS in consideration), a MAC Address TLV and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. " To be precise the LDP Address Withdraw Message base specification don't contain the FEC TLV, and I actually can't find where it has been specified as an optional TLV for the Address Withdraw Message. After re-reading the draft once more, and refering to the base LDP specification it is my impression that a major rework of the draft would be in place to align with the LDP concepts, terminology and style. /Loa > > I agree with the other comments from the group which call for > clarification. > > Marc > > ----- Original Message ----- From: "Luca Martini" > To: "Loa Andersson" > Cc: "L2VPN" ; ; "Rick Wilder" > ; "Bill Fenner" ; > "Mark Townsley" ; "Margaret Wasserman" > ; "Vach Kompella" > Sent: Monday, April 25, 2005 6:53 PM > Subject: [mpls] Re: Summary: mpls wg review of > thedraft-ietf-l2vpn-vpls-ldp-06.txt > > >> Loa, >> >> Comments in line... >> >> ..... >> >>> >>> Targeted LDP sessions >>> ---------------------- >>> One recurring theme is that a choice to use LDP to signaling >>> vpls de-multiplexors will lead to a full mesh of targeted >>> ldp session between PEs. It has been appointed out that this >>> will potentially cause scaling problems. >>> >>> WG-chair comment: LDP was never intended to support a full mesh of >>> targeted LDP sessions. >>> >>> >>> If LDP is used in this way it must clearly be stated that this is a >>> factor that will limit the scaling of the vpls application, >>> However this is nothing the changes or affects the workings of >>> other usages of LDP. This is local to this draft and should be >>> handled here. >>> >> I would like someone to actually substantiate that there would be a >> problem with a large number of targeted LDP sessions. >> It had been my experience that targeted LDP scales very easily beyond >> any number of session that would be deployed in this application. >> This is NOT BGP ! Let's not just assume that because BGP with hundreds >> of thousands routes, and very complex policies , does not scale in a >> full mesh environment, LDP will have the same fate. >> >> >>> MAC List TLV: >>> ------------- >>> A second point is made that the added TLV "MAC List TLV" >>> is an example of using LDP for something it was not intended >>> for. One issue here is that the already, as compared to a routing >>> protocol, long LDP convergence time could be even longer. This >>> will have effects on both "traditional" LDP convergence and the >>> vpls application. >>> >> >> As far as i remember , this is a TLV that is going to be used to >> indicate withdrawal of the mac addresses. >> When there is a link failure LDP does not advertise new IP label >> mappings, hence the only "slow down" will be in possibly withdrawing >> LDP IP label mappings ... >> And since these are targeted sessions it very likely that there will >> be no LDP ip label mappings in the first place. >> Nobody should care about LDP withdrawing IP label mapping , as the IGP >> is the master , and determines the convergence time. >> So what is going to be slowed down ? >> >>> The encoding of this TLV is not clearly defined. >>> First the diagram of the TLV depicts MAC addresses that are >>> only 4 bytes long. >>> Second, given the historic confusion between IEEE and IETF >>> encodings some discussion of bit and byte order and some >>> pointers to documents such as RFC1042 would be in order. >>> >>> WG-chair comment: >>> The MPLS working group is concerned about this issue. However >>> we need a better understanding of the dynamics involved before >>> a recommendation can be made. >>> >>> The text on the usage of this TLV is very difficult to parse. >>> Some clean-up is needed. Further use of this TLV should be >>> incorporated into the examples. >>> >>> Use of Generalized PWid FEC Element >>> ----------------------------------- >>> >>> Several fields are not clearly specified. >>> >>> E.g. in section 4.1.1: >>> >> Control bit (C): Depending on whether, on that particular PW, the >>> >> control word is desired or not, the control bit may be specified. >>> >>> >>> simply say: >>> >>> This bit is used to signal use of the control word as specified in >>> [PWE3-CTRL]. >>> >>> >>> >> PW type: The allowed PW types in this version are Ethernet and >>> >> Ethernet VLAN. >>> >>> >>> The phrase "in this version" should be deleted. >>> >>> >>> >> AGI Type field >>> >>> Either a value should be specified (along with a corresponding format) >>> or it should be stated how values are to be selected. >>> >>> >>> >> - Requested VLAN ID: If the PW type is Ethernet VLAN, this >>> >> parameter may be used to signal the insertion of the >>> >> appropriate VLAN ID. >>> >>> >>> This looks under specified. >>> >>> >>> >> Section 7. Operation of a VPLS >>> >>> Since FEC 128 has been moved to an appendix, this section should be >>> recast in terms of FEC 129. >>> >>> >> Section 8.2.2. Failure detection and recovery >>> >>> The hello message only detect control plane failures and not at a >>> particularly fast rate. If fast detection is needed, then >>> VCCV or BFD on the PSN tunnel should be employed. >>> >>> >>> MD5 and security >>> ---------------- >>> >>> A third point that has been made is that the security >>> considerations of the LDP specification were never designed >>> to meet the requirements of VPLS. >>> >>> WG-chair comment: This would definitely be of great concern, >>> but again it does not effect the LDP as a protocol but is >>> limited to the usage of LDP in this application. >>> >> this document should probably point to the pwe3 document and it's >> security section ... >> >> Luca >> >>> >>> /Loa and George >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls >> >> > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 10 21:33:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVg6N-0001kT-O0; Tue, 10 May 2005 21:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVg6L-0001kL-B2 for mpls@megatron.ietf.org; Tue, 10 May 2005 21:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11279 for ; Tue, 10 May 2005 21:33:27 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVgLj-0004ug-R6 for mpls@ietf.org; Tue, 10 May 2005 21:49:25 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WJoJ012641; Wed, 11 May 2005 10:32:19 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WINe011075; Wed, 11 May 2005 10:32:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WInp011055; Wed, 11 May 2005 10:32:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WHK7027339; Wed, 11 May 2005 10:32:17 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WH8q027334; Wed, 11 May 2005 10:32:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WHeN022897; Wed, 11 May 2005 10:32:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WGW8016657; Wed, 11 May 2005 10:32:16 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j4B1WGG8016649; Wed, 11 May 2005 10:32:16 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id KAA15660; Wed, 11 May 2005 10:32:15 +0900 (JST) Message-Id: <5.0.2.5.2.20050511102247.07ca4d50@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 11 May 2005 10:48:17 +0900 To: From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [mpls] draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.tx X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi all, Please note that we have submitted draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-00.txt to start the discussion of the support of multicast LDP over MPLS P2MP TE LSPs. The abstract is as follows... > Multiprotocol Label Switching (MPLS) includes the facility to > provision point-to-multipoint (P2MP) Traffic Engineered (TE) Label > Switched Paths (LSPs) which can be used to construct P2MP tunnels > across MPLS networks. > > The Label Distribution Protocol (LDP) has also been extended to > support label distribution for multicast traffic by forming multicast > LSPs. > > When traffic for a user network is carried across a provider network, > it is common practice for the traffic to be placed in tunnels. This > document examines the requirements to carry multicast MPLS traffic > across a provider network within P2MP MPLS tunnels, and sets out > solutions that meet those requirements. It is obviously early to be discussing this as the ideas for multicast LDP have not been agreed yet, but we thought that there was sufficient similarity in the proposals to make this new I-D worthwhile. We would be very pleased to receive your feedback. Thanks, Seisho _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 10 22:50:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVhIo-00006O-6H; Tue, 10 May 2005 22:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbtZ-0007E8-G2; Tue, 10 May 2005 17:04:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20442; Tue, 10 May 2005 17:03:58 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVc8w-0007rU-Mq; Tue, 10 May 2005 17:19:55 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j4AL2ITs010373; Tue, 10 May 2005 16:02:19 -0500 (CDT) Received: from harlem (harlem.dnrc.bell-labs.com [135.180.161.4]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j4AL2GS09674; Tue, 10 May 2005 17:02:16 -0400 (EDT) Date: Tue, 10 May 2005 17:02:17 -0400 (EDT) From: Thyaga Nandagopal X-X-Sender: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Tue, 10 May 2005 22:50:24 -0400 Subject: [mpls] COMSWARE 2006: Call for Papers X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on Communication Systems Software and Middleware COMSWARE 2006 http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor: IEEE Communications Society, Indian Institute of Technology, Delhi In Co-operation with: ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA), IBM, Microsoft Research, NOKIA, Lucent Technologies, Sasken The convergence of the communications, information technologies and the Int= ernet has ushered in a revolution in the way people communicate with each other. = The key enabler for this convergence has been the advancement of software technolog= y in various communication sectors, as evident by the high levels of activity in= the industry, academia, and standards bodies, coupled with the increasing depen= dence of this convergence to sustain and improve growth rates in many countries arou= nd the world. This new international conference will provide a forum to exchange ideas, t= echniques, and applications, discuss best practices and challenging issues, raise awar= eness and share experiences among researchers, practitioners, standard developers and= policy makers in the field of software techniques in communications. The conferenc= e will bring leading researchers and practitioners in areas ranging from communica= tions software and software engineering aspects of communications software, to mi= ddleware and networking protocols. The objective of the conference is to provide a h= igh degree of collaboration, participation and discussions of the various topic= s among multi-national participants from the industrial, governmental and academic = sectors. COMSWARE will include a regular paper track and an industry track. The pape= r track will include a highly selective technical program. The conference solicits = original, previously unpublished research work, experimental efforts, and practical e= xperiences for the technical program. COMSWARE will also feature panel discussions fro= m experts in academia and industry, workshops and tutorials featuring the state-of-th= e-art in various communications software and related areas. There will be demos and = exhibits that will expose the delegates to exciting products and software solutions = from industry and academia. Accepted papers will be published by IEEE Computer S= ociety. The top papers accepted to the conference will be published in a reputed jo= urnal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 4, 2005 (Instructions at http://www.comsware.org) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs:=09=09Victor Bahl, Microsoft Research, USA =09=09=09Bijendra Nath Jain, IIT, Delhi, India =09=09=09Henning Schulzrinne, Columbia University, USA =09=09=09Alfred Spector, IBM Research, USA Steering Committee:=09Imrich Chlamtac, University of Trento, Italy =09=09=09Rajeev Shorey, IBM Research, India =09=09=09Prasant Mohapatra, University of California, Davis, USA Program Chairs:=09=09Sanjoy Paul, Lucent Technologies, USA =09=09=09G. Venkatesh, SASKEN Technologies, India =09=09=09Jim Woodcock, University of York, UK Tutorial Chair:=09=09Archan Misra, IBM Research, USA Workshop Chairs:=09Ashwin Gumaste, Fujitsu Research, USA =09=09=09Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Co-Chairs: Sudipta Maitra, IBM, Delhi Laurent Mignet, IBM Research, Delhi Finance Chair: Karen Decker, USA _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 11 06:24:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVoO2-0007Qq-PO; Wed, 11 May 2005 06:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVoO0-0007OV-SD for mpls@megatron.ietf.org; Wed, 11 May 2005 06:24:16 -0400 Received: from gondor.rs.riverstonenet.com (lan-202-144-106-188.maa.sify.net [202.144.106.188] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19736 for ; Wed, 11 May 2005 06:24:12 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 11 May 2005 15:53:41 +0530 Message-ID: Thread-Topic: Is it possible to create FEC with multiple/disparate prefixes ? Thread-Index: AcVWE4D1T3w8Nby9RBKHnGb6Edp1Ag== From: "Dutta, Pranjal" To: Cc: Subject: [mpls] Is it possible to create FEC with multiple/disparate prefixes ? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160636420==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1160636420== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55613.818AD3FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55613.818AD3FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I would like to know if it is possible to create a single FEC for Multiple Prefixes in the routing table and distribute across the domain through LDP (preferably for Down Stream Unsolicited Mode). One case would be when multiple prefixes that can't be aggregated/super netted (by the egress) follow the same path from ingress LSR to the egress LSR. Will it be same as FEC aggregation? If it is possible then how ingress LSR will know that all such disparate prefixes follows the same path till egress and accordingly classifies all of them into the same LSP. =20 =20 Thanks in advance, =20 Pranjal ------_=_NextPart_001_01C55613.818AD3FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

         =         I would like to know if it is = possible to create a single FEC for Multiple Prefixes in the routing table and = distribute across the domain through LDP (preferably for Down Stream Unsolicited Mode). = One case would be when multiple prefixes that can’t be aggregated/super = netted (by the egress) follow the same path from ingress LSR to the egress LSR. = Will it be same as FEC aggregation? If it is possible then how ingress LSR will = know that all such disparate prefixes follows the same path till egress and = accordingly classifies all of them into the same LSP.

 

 

Thanks in advance,

 

Pranjal

------_=_NextPart_001_01C55613.818AD3FE-- --===============1160636420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1160636420==-- From mpls-bounces@lists.ietf.org Wed May 11 06:37:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVobH-0001ng-Ft; Wed, 11 May 2005 06:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVobF-0001nZ-WF for mpls@megatron.ietf.org; Wed, 11 May 2005 06:37:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20929 for ; Wed, 11 May 2005 06:37:52 -0400 (EDT) Received: from [202.144.106.188] (helo=gondor.rs.riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVoqh-0006aF-2U for mpls@ietf.org; Wed, 11 May 2005 06:53:56 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 11 May 2005 16:07:40 +0530 Message-ID: Thread-Topic: Is it possible to Create a FEC with Multiple Disparate Prefixes? Thread-Index: AcVWFXT9HmQxWNT5RGm8UCRwUoTRZQ== From: "Dutta, Pranjal" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Subject: [mpls] Is it possible to Create a FEC with Multiple Disparate Prefixes? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0696657078==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0696657078== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55615.758E8F4F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55615.758E8F4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I would like to know if it is possible to create a single FEC for Multiple Prefixes in the routing table and distribute across the domain through LDP (preferably for Down Stream Unsolicited Mode). One case would be when multiple prefixes that can't be aggregated/super netted (by the egress) follow the same path from ingress LSR to the egress LSR. Will it be same as FEC aggregation? If it is possible then how ingress LSR will know that all such disparate prefixes follows the same path till egress and accordingly classifies all of them into the same LSP. =20 =20 Thanks in advance, =20 Pranjal =20 ------_=_NextPart_001_01C55615.758E8F4F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

         =         I would like to know if it is possible to create a single FEC for = Multiple Prefixes in the routing table and distribute across the domain through = LDP (preferably for Down Stream Unsolicited Mode). One case would be when = multiple prefixes that can’t be aggregated/super netted (by the egress) = follow the same path from ingress LSR to the egress LSR. Will it be same as FEC aggregation? If it is possible then how ingress LSR will know that all = such disparate prefixes follows the same path till egress and accordingly = classifies all of them into the same LSP.

 

 

Thanks in advance,

 

Pranjal

 

------_=_NextPart_001_01C55615.758E8F4F-- --===============0696657078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0696657078==-- From mpls-bounces@lists.ietf.org Wed May 11 12:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuGb-0003QT-1U; Wed, 11 May 2005 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVuGY-0003QK-JB for mpls@megatron.ietf.org; Wed, 11 May 2005 12:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22498 for ; Wed, 11 May 2005 12:40:55 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVuW5-0000rZ-S5 for mpls@ietf.org; Wed, 11 May 2005 12:57:03 -0400 Received: from h-68-164-88-190.snvacaid.dynamic.covad.net ([68.164.88.190] helo=earthlink.net) by pop-a065d19.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DVuGP-0001Hv-00; Wed, 11 May 2005 09:40:49 -0700 Message-ID: <4282374C.E3810B57@earthlink.net> Date: Wed, 11 May 2005 09:48:12 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Dutta, Pranjal" Subject: Re: [mpls] Is it possible to create FEC with multiple/disparateprefixes ? References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 2.9 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA22498 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Pranjal, et al, I must be lost... In the simplest case, why could't a MPLS domain use single FEC and a single LSP? IMO, no it wouldn't be the same because you are not aggregating a set of discontinous=20 network addresses. It basicly is the same as a=20 static route. My guess, this is either a non-changing routing environment, or at this point in time, alternate routes are not available. You wouldn't be doing any load balancing with your traffic, but it would make sense if your MPLS domain were say transiting a single path satelite link. Mitchell Erblich ---------------------------- =09 =09 > "Dutta, Pranjal" wrote: >=20 > Hi All, >=20 > I would like to know if it is possible to create a > single FEC for Multiple Prefixes in the routing table and distribute > across the domain through LDP (preferably for Down Stream Unsolicited > Mode). One case would be when multiple prefixes that can=92t be > aggregated/super netted (by the egress) follow the same path from > ingress LSR to the egress LSR. Will it be same as FEC aggregation? If > it is possible then how ingress LSR will know that all such disparate > prefixes follows the same path till egress and accordingly classifies > all of them into the same LSP. >=20 >=20 >=20 >=20 >=20 > Thanks in advance, >=20 >=20 >=20 > Pranjal >=20 > --------------------------------------------------------------- > _______________________________________________ > 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 From mpls-bounces@lists.ietf.org Wed May 11 22:27:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3QM-0006Nt-Qj; Wed, 11 May 2005 22:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3QL-0006No-JX for mpls@megatron.ietf.org; Wed, 11 May 2005 22:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21281 for ; Wed, 11 May 2005 22:27:39 -0400 (EDT) Received: from mdsnwi16-vlan463-209.dsl.tds.net ([216.170.241.209] helo=argus.dangermen.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3fy-0001sA-0w for mpls@ietf.org; Wed, 11 May 2005 22:43:51 -0400 Received: from argus.dangermen.com (localhost [127.0.0.1]) by argus.dangermen.com (8.12.10/8.12.4) with ESMTP id j4C2W737020170; Wed, 11 May 2005 21:32:07 -0500 Received: (from jleu@localhost) by argus.dangermen.com (8.12.10/8.12.4/Submit) id j4C2W6ej020169; Wed, 11 May 2005 21:32:06 -0500 X-Authentication-Warning: argus.dangermen.com: jleu set sender to jleu@mindspring.com using -f Date: Wed, 11 May 2005 21:32:06 -0500 From: "James R. Leu" To: "Dutta, Pranjal" Subject: Re: [mpls] Is it possible to create FEC with multiple/disparate prefixes ? Message-ID: <20050512023206.GA17800@mindspring.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jleu@mindspring.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161417814==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0161417814== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I published a draft back in 2000 that described a technique for accomplishi= ng something similar to what you're asking for. It only worked for the LDP DoD case though. Google for draft-leu-mpls-ldp-label-aggregation-00 On Wed, May 11, 2005 at 03:53:41PM +0530, Dutta, Pranjal wrote: > Hi All, >=20 > I would like to know if it is possible to create a > single FEC for Multiple Prefixes in the routing table and distribute > across the domain through LDP (preferably for Down Stream Unsolicited > Mode). One case would be when multiple prefixes that can't be > aggregated/super netted (by the egress) follow the same path from > ingress LSR to the egress LSR. Will it be same as FEC aggregation? If it > is possible then how ingress LSR will know that all such disparate > prefixes follows the same path till egress and accordingly classifies > all of them into the same LSP. >=20 > =20 >=20 > =20 >=20 > Thanks in advance, >=20 > =20 >=20 > Pranjal >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --=20 James R. Leu jleu@mindspring.com --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQFCgsAmQcSCk6yg8WERAur5AJ9zbnW/8tleaJ8xSi84bKDuqna1ywCcCURU 4b0yDlpg0aSWhWQmamy8M8Q= =Rk9R -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- --===============0161417814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0161417814==-- From mpls-bounces@lists.ietf.org Wed May 11 23:19:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4EM-0008JL-Jp; Wed, 11 May 2005 23:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4EK-0008JG-2C for mpls@megatron.ietf.org; Wed, 11 May 2005 23:19:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24729 for ; Wed, 11 May 2005 23:19:16 -0400 (EDT) Received: from [202.144.106.188] (helo=gondor.rs.riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW4Tw-0004XT-3s for mpls@ietf.org; Wed, 11 May 2005 23:35:29 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Is it possible to create FEC with multiple/disparate prefixes ? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 12 May 2005 08:48:56 +0530 Message-ID: Thread-Topic: [mpls] Is it possible to create FEC with multiple/disparate prefixes ? Thread-Index: AcVWmjC64TCWKD7TR/iFpKhR+2EeDQABe3dg From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Thank you very much...even I was thinking if aggregation could be done then the signaling should follow the DoD model. Why aggregation came to my mind is that although aggregation leads to loss of granularity, in ingress LSR if Label space is exhausted(means almost all labels are used already) it's good to have some capability to aggregate some FECs to a "Master FEC" on the precondition that all aggregated FECs followed the same path before. And loss of granularity might not harm much in the core where label exhaustion might be possible. Please correct me if I have missed some major point in my assumptions. Thanks, Pranjal -----Original Message----- From: James R. Leu [mailto:jleu@mindspring.com]=20 Sent: Thursday, 12 May, 2005 8:02 AM To: Dutta, Pranjal Cc: mpls@ietf.org Subject: Re: [mpls] Is it possible to create FEC with multiple/disparate prefixes ? I published a draft back in 2000 that described a technique for accomplishing something similar to what you're asking for. It only worked for the LDP DoD case though. Google for draft-leu-mpls-ldp-label-aggregation-00 On Wed, May 11, 2005 at 03:53:41PM +0530, Dutta, Pranjal wrote: > Hi All, >=20 > I would like to know if it is possible to create a > single FEC for Multiple Prefixes in the routing table and distribute > across the domain through LDP (preferably for Down Stream Unsolicited > Mode). One case would be when multiple prefixes that can't be > aggregated/super netted (by the egress) follow the same path from > ingress LSR to the egress LSR. Will it be same as FEC aggregation? If it > is possible then how ingress LSR will know that all such disparate > prefixes follows the same path till egress and accordingly classifies > all of them into the same LSP. >=20 > =20 >=20 > =20 >=20 > Thanks in advance, >=20 > =20 >=20 > Pranjal >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --=20 James R. Leu jleu@mindspring.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 11 23:33:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4Rt-0001yZ-PC; Wed, 11 May 2005 23:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW4Rp-0001sZ-WD for mpls@megatron.ietf.org; Wed, 11 May 2005 23:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25764 for ; Wed, 11 May 2005 23:33:14 -0400 (EDT) Received: from [202.144.106.188] (helo=gondor.rs.riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW4hT-0005BU-Gj for mpls@ietf.org; Wed, 11 May 2005 23:49:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Is it possible to create FEC with multiple/disparateprefixes ? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 12 May 2005 09:03:05 +0530 Message-ID: Thread-Topic: [mpls] Is it possible to create FEC with multiple/disparateprefixes ? Thread-Index: AcVWSDMOFDxapcq2S4izO03Dy1b+YAAWUpXA From: "Dutta, Pranjal" To: "Erblichs" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, The aggregation case I was considering, if the ingress router has a depletion of its label space or also when I am using only best effort LSPs. In the first case, the ingress LSR can aggregate some FECs (discontinuous network addresses) and map to the same Label, provided the ingress router has the way to send aggregation info till the egress point(That we can do with DoD signaling). In the second case, when I am using only best effort LSPs I don't care about loss of granularity but only a fast switching path. You are very right that if we aggregate discontinuous network prefixes then we need to have static path for all those FECs, as routing protocol might keep choosing disparate paths of the aggregated FECs depending on the network condition. Thanks and regards, Pranjal -----Original Message----- From: Erblichs [mailto:erblichs@earthlink.net]=20 Sent: Wednesday, 11 May, 2005 10:18 PM To: Dutta, Pranjal Cc: mpls@ietf.org Subject: Re: [mpls] Is it possible to create FEC with multiple/disparateprefixes ? Pranjal, et al, I must be lost... In the simplest case, why could't a MPLS domain use single FEC and a single LSP? IMO, no it wouldn't be the same because you are not aggregating a set of discontinous=20 network addresses. It basicly is the same as a=20 static route. My guess, this is either a non-changing routing environment, or at this point in time, alternate routes are not available. You wouldn't be doing any load balancing with your traffic, but it would make sense if your MPLS domain were say transiting a single path satelite link. Mitchell Erblich ---------------------------- =09 =09 > "Dutta, Pranjal" wrote: >=20 > Hi All, >=20 > I would like to know if it is possible to create a > single FEC for Multiple Prefixes in the routing table and distribute > across the domain through LDP (preferably for Down Stream Unsolicited > Mode). One case would be when multiple prefixes that can't be > aggregated/super netted (by the egress) follow the same path from > ingress LSR to the egress LSR. Will it be same as FEC aggregation? If > it is possible then how ingress LSR will know that all such disparate > prefixes follows the same path till egress and accordingly classifies > all of them into the same LSP. >=20 >=20 >=20 >=20 >=20 > Thanks in advance, >=20 >=20 >=20 > Pranjal >=20 > --------------------------------------------------------------- > _______________________________________________ > 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 From mpls-bounces@lists.ietf.org Fri May 13 16:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgrh-0004Ra-RT; Fri, 13 May 2005 16:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWgre-0004RV-L6 for mpls@megatron.ietf.org; Fri, 13 May 2005 16:34:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06041 for ; Fri, 13 May 2005 16:34:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWh7b-0003Su-Pf for mpls@ietf.org; Fri, 13 May 2005 16:51:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 May 2005 16:34:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4DKYDnK022785; Fri, 13 May 2005 16:34:16 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 16:34:13 -0400 Received: from swallow-mac.cisco.com ([10.86.241.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 16:34:13 -0400 Received: by swallow-mac.cisco.com (Postfix, from userid 501) id CC3B82F61EA; Fri, 13 May 2005 16:34:10 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 15F222F61DE; Fri, 13 May 2005 16:34:10 -0400 (EDT) To: "M. elk" Subject: Re: [mpls] Clarification reg LSP PING - Draft ver 08- Part 3/3 In-reply-to: Your message of "Mon, 02 May 2005 14:27:24 +0300." From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Fri, 13 May 2005 16:34:08 -0400 Message-Id: <20050513203410.CC3B82F61EA@swallow-mac.cisco.com> X-OriginalArrivalTime: 13 May 2005 20:34:14.0040 (UTC) FILETIME=[204F4180:01C557FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: c2c13da073bbdd073b64ce7ea2347217 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Although the last call closed a month prior to your messages, I felt your comments were serious enough to give them full consideration. Thanks for the close read. Attached are my responses. ...George ======================================================================== > A- Section 3 , Packet Format A1. For "If the normal IP return path is > deemed unreliable ,one may use "Reply via an IPV4/IPV6 UDP Packet with > Router Alert " . > > Actually it was not clear how using such mode of reply will > increase the chance to receive the reply packet . In some > external presentation , it is explained as the reply will be > routed in a transient LSR by the RP(instead of the LC ) and as > such the reply packet will be correctly routed in the case where > the FIB of the LC is corrupted . May be it worth to document this > explanation into the draft . I don't believe this draft is the proper place for this kind of tutorial information. > What about "Reply and log " , in this case the operator could > check the remote end to see if any log in case of no reply > received . For sacalability , The receiving station count the nbr > of echo request for each (Source IP Address,Source UDP port , > Sender Handle). and/or "Reply Via NMS" ,path from any node to NMS > is the most watched path (from OPS perspective) and we could > assume it is up (otherwise it is currently under attention of the > operator ) . In this mode the node encapsulate the reply in > IP-in-IP through the NMS . The entire philosophy of ping is based on most of the work being done at the point where the ping is initiated. If an implementation wants to provide logging they can. If they want to allow it to be turned on and off they can. They just have to tell the tail end prior to sending the pings. > A2.For "TLVs may be nested within other TLV ......" > The above indicate that we could liberally nest TLV within TLV , > but actually it is not the case . We do have strict TLV and > SUB-TLV as the "Type" field of the TLV and SUB-TLV do Overlap . > In other word : TLV could not appear inside another TLV . SUB-TLV > could not appear unless inside TLV . Updated text to: Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a four-octet boundary. TLVs may be nested within other TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs have independent types and must also be four-octet aligned. > A3. For Target-FEC-Stack TLV contain 1) Sub-TLV LDP IPv4 and 2)Sub-TLV VPN IPV4 Prefix > the length could be : i) 24 or j) 20 ? > For 24 , each SUB-TLV is aligned to four-octet-boundary . > For 20 , the TLV ( as a whole) is aligned to four-octet-boundary > > If the draft recommend the way to align each sub-TLV to > four-octet-boundary(length = 24) ,but in such case why the length > value of the SUB-TLV was chosen not to include the padding byte > ?? ex: For LDP IPv4 the length is 5 instead of 8 . The "length" > field should specify the actual size (in this case 8) used on the > wire , the receiving node from the "Type" field could determine > that the used part is just 5 . Else (length = 20) , could we > modify the example to include more than one Sub-TLV to make the > case clearer . Actually the answer is 32. Updated the example as follows: The Length for this TLV is 5. A Target FEC Stack TLV which contains an LDP IPv4 FEC sub-TLV and a VPN IPv4 FEC sub-TLV has the 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 = 1 (FEC TLV) | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 6 (VPN IPv4 FEC) | Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > A4. For the Para (page 10) "Types less than 32768 ....etc " . > may be changing the word "mandatory" to "mandatory supported " . > > For the Para (page 10) "Types greater than .....etc " . > may be changing the word "optional " to "optionally supported" > > This will make it more clear that "mandatory" and "optional" > refer to the support of the node for such TLV's and not the > existence of such TLV in the packet . Fixed. > A5. Section 3.2 page 12 . > > for the Sub-TLV "RSVP IPv4 Session Query" , better to be named > as just "RSVP IPv4 Session" . same for IPv6 . Changed to RSVP IPv4 LSP > A6. Page 12 , the Para "say LSR X wanted ...etc ". > is this applicable to "LSP Trace" also ??? > > For the case where RSVP Tunnel end at the destination PE (Target > FEC TLV could contain RSVP IPV4 session Sub-TLVand IP VPN Prefix > Sub-TLV. or Target FEC could contain just the IP VPN Prefix > Sub-TLV ) , is it workable for "LSP Trace". > > (The point that in case the target FEC contain just the IP VPN > Sub-TLV , the transient LSR will find no Sub-TLV FEC which > correspond to the RSVP LSP or the LDP LSP so how this LSR could > check ) . Only checks if there's a valid DS map (section 4.4) > The confusing point that a transient LSR in some cases is able > to check the received label against the target FEC ,and in other > cases it is not possible . Is it correct ?? If yes : How the > transient LSR could differentiate . > > N.B: may be the answer to above is within section 4.4 (Receiving > an MPLS echo request) ,but i am having difficulty to understand > section 4.4 . > > A7. NIL FEC > One usage for "NIL FEC" is documented in section 4.2 . Any other > usage not documented in the draft ??? Not at this time. > B. Downstream Mapping TLV , Page 20 > > B1 . For "Only one downstream mapping request may appear in am echo > request " > change "downstream mapping request" to "downstream mapping > object" . done. > B2. For "Otherwise Downstream mapping objects should include a > downstream mapping object > ............could be forwarded" . > The DS TLV do not include DS TLV . May be rewriting the > above as > "Otherwise ,the echo reply should include a downstream > mapping object .......could be forwarded". fixed. > B3. Moving the "I" Flag to be global flag . > why : The Requirement is to know the Destination " > interface and label stack" object . > Currently: U have to Trace the full path to get those info > . > what is needed : Just using PING and requesting the > "Interface and label Stack" object to be > included in the echo reply . You can send a DS without setting the TTL low. Use a neighbor address of 127.0.0.1 (unknown). > B4. Multipath Type , Page 22 > > The Sending LSR have the following to influence the multipath > : > i) The destination IP , which need to be chosen from the 127/8 > range . > and/or > ii) The Source UDP Port . > > The Transient LSR (where the TTL expire) have the following info > : > i) the source IP ,Destination IP and the source UDP Port . > ii) The received label Stack , say {Ln,Ln-1,....L1} > iii) The Received DS Mapping TLV > > Case 1- The "N" Flag set to indicate non-IP Packet > > Sub-case 1a- The LSR consider only the Received Label stack . Run > is Hash function (assuming avail of > more than one interface , say intfa and > intfb ) on the received label stack to find out on which > interface it will be forwarded , say > Intf_a > The LSR reply with DS mapping TLV with > intfa details and with "Multipath type" = zero . > > Sub-Case 1b- The LSR consider the Received label Stack and the > info of the multipath type > (Multipath Type = 9 or Zero ) received > . For simplicity assume no info for the "Multipath Type" > i.e.: "Multipath Type" = Zero . 1a is correct. If there's no multipath info then you don't reply with multipath info (send back type 0). You just show what interface you would have forwarded this packet on. > The LSR run his Hash and find 2 bit-masked > label set (say bit_masked_set_1 and bit_masked_set_2). > one which will forward the packet to intfa > and the other to intfb . The LSR reply by 2 DS mapping > TLV both with "MultiPath type" = 9 . But : > the only possible values for both set (Bit_masked_set_1 , > Bit_masked_set_3) are the Explicit null > label or Router Alert label. is it correct ??? > Say Bit_masked_set_1 resolve to Explicit > null , could it be used by the sending LSR more than once . > ex: > {Ln,Ln-1,Ln-2,......,Explicit_null,Explicit_null,L1} and still get > forwarded to intfa ???. > is it location independent ,ex: > {Ln,Explicit_Null,Ln-1,.......L1} same as > {Ln,Ln-1,Explicit_null,Ln-2,.....L1} , > both will be forwarded to intfa ???. I don't get the meaning of the list in parens. If it's a label stack the answer is no. > For Case 1 , Is it sub-case 1a or Sub-case 1b ??? . > > Case 2 - The "N" Flag cleared to indicate IP Packet . > > Sub-Case 2a- The Transient LSR consider the following when > calculating the hash : > i) The Source IP Address . > ii) The Source UDP port . > iii) The multipath info received ( Multipath > Type = Zero,or 2 or 4 or 8 ) > > Sub-case 2b- The Transient LSR consider the following when > calculating the hash : > i) The Source IP Address . > ii) The Source UDP port . > iii) The multipath info received ( Multipath > Type = zero, or 2 or 4 or 8 ) > iv) the received label stack . > > Sub-Case 2c- The Transient LSR consider the following when > calculating the hash : > i) The Source IP Address . > ii) The Source UDP port . > iii) The multipath info received ( Multipath > Type = zero, or 2 or 4 or 8 or 9 ) > iv) the received label stack . > > which sub-case is valid ??? . Depends on how the implementation does it's hashing. So 2b, and 2c (they seem to be the same) is correct. But if the implementation doesn't include the label stack when forwarding then it doesn't use it here either. > B5. The Filed "Depth Limit" ,page 22 > Guess this filed should be ignored (or set to zero) when the > DS mapping TLV is part of Echo request . > This field is populated by the LSR sending the echo reply to > indicate the number of labels out from > the received label stack considered in the hash . is it > correct ?. Not quite. Some hardware has limitations on how deeply it can inspect a packet in the fast path. If at a certain label stack depth it has to alter it's behavior (such as I hash only on the bottom label as long as there are 4 or fewer labels, but I hash on the 4th label if there are more) then the Depth Limit is there to let you know to whatch out for alternate behavior with deep label stacks. > if yes : consider > the Transient LSR received label stack {L3,L2,L1} and DS > Mapping TLV > The transient LSR reply with DS mapping TLV with label field > {L4,L2,L1} and Depth-limit=2 > is it mean that LSR will do the hah over {L3,L2} or {L2,L1} > or even {L3,L1} ??? > > B6. Protocol , page 23 > Consider PE1----P1----P2----PE2 . > The PE1 send echo request with TTL=1 and DS mapping TLV. > The DS mapping TLV contain the 2 label , {(L1,LDP),(L2,IP > VPN)} > P1 send echo reply with DS mapping TLV . > The DS mapping TLV contain the 2 label as : > i) {(L3,LDP),(L2,IP VPN)} > or > ii) {(L3,LDP),(L2,Unknown)} Any label that you haven't processed you leave as is. > In the first case , P1 copy the protocol of L2 from the DS > mapping TLV received . > In the 2nd case ,P1 have no self info which protocol issued L2 > so it mark L2 with Unknown protocol > irrespective of what protocol was associated with L2 in the > received DS mapping TLV . > > so which case the draft is calling for ?? . > > B7. Multipath info encoding , page 23 > > B7.1 For the first Para "The multipath info encodes labels > ..........". > The sentence "The contents of the fields are shown in the > table above", Added pointer back to section. > It seems the table is missing . > The sentence "Label and Address pairs .....", in this ver > of the draft the "multipath type" = 1 = label > is deprecated . Also , what it meant by "pairs" ??? . added some clarifying text > B7.2 For "multipath type" = 8 or 9 encoding . could we have an > example to make it clear . Added examples. > B7.3 For the Para " if the received multipath information is > ........". > For the sentence " if the received multipath information > is non-null," , is it mean > "If their is DS mapping TLV received " ???. > > For " if the received multipath information is null" , is > it mean > " If their is no DS mapping TLV received " . > > For "The type must be set to 0" , is it Zero or 7 > (no-match) ?? 0 - we dropped 7. > Re-writing the Para as : > > "If their is Downstream Mapping TLV received ,the labels > and IP address MUST be picked from > the set provided . if none of these labels or addresses > map to a particular downstream interface , > then in the downstream mapping TLV for that interface in > the echo reply ,the multipath type must > be set to 7 (no match) . If their is no DS mapping TLV > received ,the receiver LSR simply return no > Downstream mapping TLV in the echo reply ". rewrote as: labels or addresses map to a particular downstream interface, then for that interface, the type MUST be set to 0. If the received multipath information is null, (i.e. Multipath Length = 0, or for Types 8 and 9 a mask of all zeroes) the receiver the type MUST be set to 0. > > B7.4 for the Para "For Example ,suppose ..........." . > my understanding that the address should be in the 127/8 > range ???. Changed ranges. > For " with Hash key Type 7 " , in this ver of the draft the > Hash key is renamed multipath Type . > Also , in this ver multipath-Type = 7 is not defined (only 0 > ,2,4,8 and 9 ). Fixed, now 0. > For " The Head end reflects ...." , could we elaborate in > the draft how this is done .guess this > will make it clearer for the reader . > > An example of using label to exercise path ,will be very > useful . > > B7.5 For the Para "Note that computing .....". > Could we have it as explicit notification(instead of > implicit) ,say by setting certain global flag in the > echo reply . I think it's clear enough. The info is there. > B7.6 For " If a packet was originated with TTL n>1 arrived with > outermost label L at LSR X ....". > Guess it could be more clear as : > " If a packet was originated with TTL n>1 arrived with > outermost label L with TTL=1 at LSR X ..." OK. > B7.7 For "Note that there are multiple downstream label fields in > each TLV as the incoming label L may be > swapped with a label stack ". > > Consider PE1----P1---Tunnel1--P2---PE2 > testing for IP VPN LSP using trace . > Case 1 : > PE1 send echo request with DS mapping TLV with label fields > : {(L1,LDP),(L2,IP VPN)} > P1 reply include DS mapping TLV with label fields > {(L3,RSVP-TE),(L4,LDP),(L2,IP VPN)}. > > OR > Case 2 : > PE1 send echo request with DS mapping TLV with label fields : > {(L1,LDP)} > P1 reply include DS mapping TLV with label fields > {(L3,RSVP-TE),(L4,LDP)}. > > is it case 1 or 2 ?? > The above note in the draft could be understood that it is > case 2 ??. > while the definition of "downstream label " in page 23 > ,indicate it is case 1 . Deleted the note as it is misleading. > B7.8 Page 25 . For the Para "The case where X is the ......." , and > the Para "the set of downstream router " . Guess by swapping the > position of the 2 Para the sequence of info will be more clearer . I don't think that change would be helpful. > B7.9 Page 25 . In the Para " The set of downstream routers ....." . > for " The "No of multipaths" is the number of IP > address/Next label fields". could U pls explain ???. Old text. Deleted. > B7.10 . The case of RSVP-TE Tunnel > consider : > > PE1--P1--P2--P3---P4--P5--PE2 > we do have RSVP-TE tunnel from P1 to P4 . > testing for IPv4 VPN > > PE1 will send Echo Request with DS mapping TLV contain the label field > {(L1,LDP),(L2,IP VPN)} > > case 1 : The RSV-TE Tunnel is Pipe or Short-Pipe > P1 will reply with echo reply with DS > mapping TLV contain the label field > {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS > IP address is P4 router_id , the DS > interface is the Tunnel tail-end which is > normally P4 router_ID. From this info PE1 > will know that his traffic will be > encapsulated into a Tunnel which start > from P1 . > > believe is beneficiary if the reply from > P1 could also include the following info : > i) That the Tunnel is Pipe or Short-Pipe > mode > ii) The Tunnel ID . > > For both , > it is satisfied by a Tunnel object (same > as specified in > draft-ietf-ccamp-tunproto-01). The intention was all along to have this kind of functionality be part of that draft. (Not planning to add it to this one.) > PE1 now have full info , it is known that traffic will be encapsulated in an RSVP tunnel which > start at P1 and end at P4 .also the Tunnel ID is known . > > Case2 : The RSVP-TE Tunnel is Uniform mode . > > P1 will reply with echo reply with DS mapping TLV contain the label field > {(L3,RSVP),(L4,LDP),(L2,IP VPN)} . The DS IP address is P2 router_id , the DS interface > is P2 interface connecting to P1 . > From this info PE1 will know that his traffic will be encapsulated into a Tunnel which start from > P1 . > > believe is beneficiary if the reply from P1 could also include the following info : > > i) That the Tunnel is Uniform mode . > ii) The Tunnel ID . > iii) the incremental step in TTL if chosen to skip the > tunnel transient node > > "i" and "ii" same as case 1 . for "iii" ,P1 will reply with "3". > In other word ,if PE1 need to skip the tunnel just add 3 to the > TTL used to reach P1 . Any "Unused" bit's in the Tunnel object could > satisfy this requirement. PE1 now have full info , it is known that > traffic will be encapsulated in an RSVP tunnel which start at P1 and > end at P4 .also the Tunnel ID is known . PE1 could decide to include > the tunnel in the trace (continue to increment the TTL by 1 ) or to > skip it (add 3 to the TTL used to reach P1). Same as above. > > B8. Page 26 , "Interface and Label Stack" object > > B8.1 This TLV considered to be optional TLV . could we state > that if the "Return code" field is non-zero, this TLV should be > included mandatory in the echo reply or at least , for all error > code where the is included/populated it is mandatory to > include this TLV in the echo reply. My intention is that one SHOULD do this. However in certain circumstance an operator may choose for security reasons not to send such information. So I don't see how it can be Mandatory. > B8.2 In "IPv4 Interface and label Stack" Object For " If the > Address type is "No Address", ..." . the format of this TLV do > not contain any field as "Address type" ?? or this ref to the > field of "Address Type" in the received Downstream mapping TLV ?? > If yes : The "Address Type" field in the received DS TLV can not > have the value "NO Address" , i.e.: "No-Address" is not a defined > value . ???. The "No address" should have been dropped. It's hanging around from a previous version of the DS map. Added an Address Type field to the this object to be consistent with the DS mapping. > B7.11 Consider the following : > > PE1--------P2 > PE1 is trace testing for LDP IPv4 . Out from P2 , it do > exist qty 2 ECMP , one of those path the mpls forwarding is > disabled . PE1 send Echo request with DS Mapping contain > label field {(L1,LDP)}. P1 will send Echo rely with > "Return code"= 9 and =1 , in addition : P1 will > include (as normal) 2 DS mapping TLV . The first one > (where Mpls is enabled ) contain label field ((L2,LDP). > The 2nd one (where Mpls is disabled) contain no label field > . > > PE1 , will be able to conclude that the "return code" is > applicable to the 2nd interface . > > Is the above is correct implementation . The return code applies only to the label stack of the received packet. We'll say IF1 is the first interface and IF2 is the second interface. So if that packet is going out IF1, then it would send a return code of 8, and if it went out IF2 the return code would be 9. Unfortunately the DS map depends on the incoming label, not the out going label. So there are a number of possibilities. If the label operation for interface 2 is POP and there is only one label in the label stack (as in your example) then you would show the labels that would be mapped to IF2, and you would return a null label stack. If there was a label stack on the packet, then you would do as you say above. > C. Page 29 , Theory of Operation > > C1. Page 29 , In the Para "FEC stack can be more complex .........". > > For " The FEC stack would contain two sub-tlv's ,the first > being a VPN IPv4 prefix,and the second being an LDP IPv4 > prefix". > > To follow the way the target FEC TLV is built also the > convention used in page 12 Para " say LSR X Wanted ....", the > above sentence to be re-written as : "The FEC stack would > contain two sub-TLV's,the first being an LDP IPv4 prefix,and > the second being a VPN IPv4 prefix." > Changed to bottom / top > C2. Page 29 , in the Para "When an MPLS echo .....". > > For " the receiver is expected to do a number of tests that > verify ...". could the draft elaborate on what are those > tests . which are applicable to the egress node and which are > applicable to a transient node . This will help to > understand/clarify the procedure in section 4.4 "Receiving an > MPLS Echo Request". The text now points to section 4.4. > C3. Page 30 , in Para "to achieve some degree ..............". > For " "Multipath Exercise" sub-TLV ". > no such sub-TLV in this ver of the draft , may be to replace with : > " Multipath field ,part of the downstream mapping TLV ". Changed to "Multipath Information" > For "The Ingress can then send MPLS echo request that exercise > these paths". Could the draft elaborate how this is done . I don't believe this draft is the proper place for this kind of tutorial information. > C4. Page 30, in Para "To detect certain ......." > For "will prevent a router from forwarding such packet out > unlabeled interfaces". guess the router here is the PHP > router and above could be re-written as : " will prevent the > PHP router from forwarding such packet out unlabeled > interface." #I don't think the proposed wording is an improvement. > C5. Page 31 , Para "The sender chooses .....". > For "However, a sender MAY choose to send a group of echo > requests with the same sequence number to improve > .............". Guess this is more relevant/practical in > trace mode . and it could be re-written as : "However , in > trace mode a sender MAY choose to send a group of echo > requests ,having the same TTL value, with the same sequence > number to improve ..............." I don't think we should make a change here. One might also do this with just a ping in a high error environment. > C6.Page 31 .Section 4.4 "Receiving an MPLS Echo Request". > > Beleieve despite almost 3.5 page ,this section is squeezed . > The Section list/state procedure/algorithm but not muh reg the > logic itself behind this procedure/algorithm. As too many > clarification requested in this section , they will be sent in > seperate msg . > > C7. Page 36 , section 4.6 "Receiving an MPLS Echo Reply". > > Para " if the echo reply contains downstream mappings , and X > wishes to traceroute further ,...." for " it should copy the > downstream Mappings into its next Echo Request (with TTL > incremented by one)." > > Why "Downstream Mappings" have an "s" . node X should copy a > single DS mapping object in the Echo Request - the DS mapping > object which correspond to the path which X need to follow- . Changed to "it SHOULD copy the Downstream Mapping(s) into its next echo request(s) > > D. Typing Error > > D1. Page 31 , Para "An MPLS echo Request Must have .........". > for " the echo request SHOULD a downstream mapping TLV". > "Have " is missing . Done. > D2. Page 9 , "The LDP IPv4 TLV has the following format : " > Replace "TLV" with "Sub-TLV". Done. > D3. Page 9 , " A FEC TLV which contain just ......." > Replace "FEC" with "Target FEC Stack " Done. > D4. Page 22 , "will serve to execise this path" . > missing "c". Done. > D5. Page 23 , "Null labels are explicitly inluded ..." > missing "c". Done. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun May 15 08:19:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXI5X-0006qs-Ku; Sun, 15 May 2005 08:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXI5V-0006q5-38; Sun, 15 May 2005 08:19:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10154; Sun, 15 May 2005 08:19:15 -0400 (EDT) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXILo-0001GA-IP; Sun, 15 May 2005 08:36:10 -0400 Received: from [127.0.0.1] (213.66.236.118) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 42650A3B00675626; Sun, 15 May 2005 14:19:04 +0200 Message-ID: <42873D93.2060300@pi.se> Date: Sun, 15 May 2005 14:16:19 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, pwe3@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'W. Mark Townsley'" , Stewart Bryant Subject: [mpls] MPLS working group review of draft-ietf-pwe3-control-protocol-16.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, the mpls wg review of the draft-ietf-pwe3-control-protocol-16.txt has ended. The comments sent to the list has been scarce and the comments from the reviewers sent directly to the working group co-chairs we see that the focus is pretty much the same as for draft-ietf-l2vpn-vpls-ldp-06.txt. Since the working group already have given its opinion on those issues we see no reason to pursue them further in this context. We have also received a large number of edititorial and style comments - those have been forwarded to wg co-chairs, ADs and authors. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon May 16 15:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSq-0007Jd-HG; Mon, 16 May 2005 15:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlSm-0007Ix-8R; Mon, 16 May 2005 15:41:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00097; Mon, 16 May 2005 15:41:14 -0400 (EDT) Message-Id: <200505161941.PAA00097@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 16 May 2005 15:41:14 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart 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 : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-09.txt Pages : 41 Date : 2005-5-16 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.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-lsp-ping-09.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-lsp-ping-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-16152047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-16152047.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Mon May 16 18:37:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoD6-0004dw-Nn; Mon, 16 May 2005 18:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXoD4-0004dQ-Kh for mpls@megatron.ietf.org; Mon, 16 May 2005 18:37:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08581 for ; Mon, 16 May 2005 18:37:10 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXoPQ-0008Dr-Dv for mpls@ietf.org; Mon, 16 May 2005 18:50:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 May 2005 15:32:36 -0700 X-IronPort-AV: i="3.93,112,1115017200"; d="scan'208"; a="636664623:sNHT30586858" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GMWSO7019274 for ; Mon, 16 May 2005 15:32:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 15:32:33 -0700 Received: from swallow-mac.cisco.com ([128.107.165.130]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 15:32:33 -0700 Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 56F84303366; Mon, 16 May 2005 18:32:32 -0400 (EDT) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 0409B303361; Mon, 16 May 2005 18:32:31 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Mon, 16 May 2005 18:32:30 -0400 Message-Id: <20050516223232.56F84303366@swallow-mac.cisco.com> X-OriginalArrivalTime: 16 May 2005 22:32:33.0139 (UTC) FILETIME=[26F10C30:01C55A67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] Last-last call on MPLS Ping X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Folks - I've updated LSP Ping in response to the issues raised in the last call. We also made a few further changes, most notably to remove the Next Hop from the BGP FECs. (this makes them consistent with the L3VPN FECs. Further there is the case where there is MPLS connectivity across providers. In that case if the PE included the next hop it knew, it would cause an error at the far end. Since the changes go beyond what has been discussed on the list, I'm making one more last call. The scope of this call is limited to the changes between drafts 8 & 9. The last call closes Monday, May 23 at 2400 UTC. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 18 05:47:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYL8v-00075c-Ln; Wed, 18 May 2005 05:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYL8t-00075M-63 for mpls@megatron.ietf.org; Wed, 18 May 2005 05:47:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27061 for ; Wed, 18 May 2005 05:47:04 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYLPo-0001IZ-Jk for mpls@ietf.org; Wed, 18 May 2005 06:04:37 -0400 Received: from [192.168.230.15] (helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DYL8a-0004zn-Cd for mpls@ietf.org; Wed, 18 May 2005 11:46:57 +0200 Message-ID: <428B0F08.50007@pi.se> Date: Wed, 18 May 2005 11:46:48 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Spam-Report: -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] moving discussion to the mpls working group list X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org MPLS working group, there has been a discussion on the rtgwg mailing list on possible extension to LDP for finding out the next-next-hop label mapping. Possible applications for this functionality world be fast reroute. Since the extensions to the LDP should be handled by the MPLS working group, this mail is to indicate that the discussion will be contiuned on the MPLS working group list. The non-MPLS part of this discussion will remain on the rtgwg mailing list. This is the content of the last mail on the rtgwg thread called "Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt)" /Loa Naiming and Stewart, you wrote - and I guess this is valid: Naiming Shen wrote: > I think the needs start emerging, any important services > riding on top of IP/MPLS transport infrastructure needs > fast convergence services. It's not reasonable to assume > only RSVP-TE LSPs need fast reroute, and other > network transport does not. This nnhop-ldp draft is to > facilitate the LDP based MPLS network for FRR with > node protection. I have been talking to some providers > in the past year, there are certainly interests in > this service. Stewart Bryant wrote: > > I think the interest that we are seeing in IPFRR for LDP > networks demonstrates the usefulness of this work. Sure > RSVP-TE FRR exists, but some customers have expressed > an interest in a solution that does not use RSVP. > However the MPLS working group need to take a decision if, when and how this functionality should be developed. The way of doing this would be - write down the requirements - send them to the mpls wg - we go through the moces to establish the mpls wg consensus Comments: - I don't think FRR for LDP based MPLS enabled IP networks should not go into the rtgwg, the charter of the rtgwg seems to say the rtgwg takes of everything that does not fit into other routing are working groups (Alex and Bill comments on this?) - my take is that for this purpose you could either document the requirements in a separate document or put them into one the existing documents. I've no preferences, but this should be rather short. - my preference would be to speed this up so we could have a decision going into the Paris meeting. Also I think it will be right to take this discussion to the mpls wg list. I will write a mail to mpls list to that effect. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 18 05:55:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYLGy-0000vh-JW; Wed, 18 May 2005 05:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYLGx-0000vK-PM for mpls@megatron.ietf.org; Wed, 18 May 2005 05:55:27 -0400 Received: from hotmail.com (bay21-f30.bay21.hotmail.com [65.54.233.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28122 for ; Wed, 18 May 2005 05:55:24 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 May 2005 02:54:56 -0700 Message-ID: Received: from 57.250.229.136 by by21fd.bay21.hotmail.msn.com with HTTP; Wed, 18 May 2005 09:54:56 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. ELK" To: mpls@ietf.org Date: Wed, 18 May 2005 09:54:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 May 2005 09:54:56.0367 (UTC) FILETIME=[A56B97F0:01C55B8F] Cc: Subject: [mpls] Fragmented LSP PING Request X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi 1) LSP PING draft , did not specify if the DF bit to be set or clear in the IP header of the LSP Echo request . One implementation always set DF bit . Any reason the draft opted to leave it unspecified ??? 2) Case :DF not set For a Transient LSR , If the LSP Echo request is "TOO-Big" to be forwarded . the LSP Echo request will be fragmented as per section 3.4 in RFC 3032 (Label Stack Encoding ) . is it correct to allow the LSP request to be fragemented ??? 3) Case : DF set . 3a) Transient LSR send ICMP as per RFC 3032 . or 3b) Transient LSR notice that the packet is LSP echo request and send echo reply directly to the Head-end (the source IP address in the echo request) with return code which indicate that fragmentation is needed . If yes: Their is no return code defined for fragmentation error ?? is it 3a or 3b . my guess it is 3a but 3b is more logical . Brgds _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 18 06:04:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYLQ2-0003rO-IG; Wed, 18 May 2005 06:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYLQ1-0003rJ-Dx for mpls@megatron.ietf.org; Wed, 18 May 2005 06:04:49 -0400 Received: from hotmail.com (bay21-f25.bay21.hotmail.com [65.54.233.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29720 for ; Wed, 18 May 2005 06:04:46 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 May 2005 03:04:18 -0700 Message-ID: Received: from 57.250.229.136 by by21fd.bay21.hotmail.msn.com with HTTP; Wed, 18 May 2005 10:04:17 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. ELK" To: mpls@ietf.org Date: Wed, 18 May 2005 10:04:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 May 2005 10:04:18.0133 (UTC) FILETIME=[F4424850:01C55B90] Cc: Subject: [mpls] LSP PING Ext for testing backup path X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi In LSP PING draft : quote The problem of probing the various flavors of backup paths that will typ- ically not be used for forwarding data unless the primary LSP is down will not be addressed here. Unquote Any other draft address/suggest a way/technique to on-line test a FRR facility ??. Or , did any manufacturer introduce a proprietary feature to do the same ??? . My guess that by extending the DS mapping TLV the FRR facility could be tested , ex: X-------Y-------Z when Y respond with echo reply ,it send qty 2 DS TLV : one for the normal path and the other for the protected one . X could excercise the protected one in his next echo request (using multipath info ). Brgds _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 18 06:42:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYM05-0007G3-CP; Wed, 18 May 2005 06:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYM03-0007Fy-FV for mpls@megatron.ietf.org; Wed, 18 May 2005 06:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03074 for ; Wed, 18 May 2005 06:42:00 -0400 (EDT) From: benjamin.niven-jenkins@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYMGy-0004a2-96 for mpls@ietf.org; Wed, 18 May 2005 06:59:33 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 11:41:52 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 May 2005 11:41:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] moving discussion to the mpls working group list Date: Wed, 18 May 2005 11:42:03 +0100 Message-ID: Thread-Topic: [mpls] moving discussion to the mpls working group list Thread-Index: AcVbjz5Wa4lTlVuDSuOeTCAgE+MDTQABXy+A To: X-OriginalArrivalTime: 18 May 2005 10:41:51.0940 (UTC) FILETIME=[33A1F040:01C55B96] X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Loa, Colleagues, I have not been following the rtgwg and I can not find any drafts on LDP next-next-hop so apologies if my questions have already been addressed. My understanding is that the path LDP uses for a flow 'tracks' the IGP and an LDP flow will take the same path through the network as an IP flow to the same destination/FEC (assuming ECMP is not running). Therefore is there really a need for LDP FRR as well as IP FRR, when LDP tracks the IGP anyway? (Or am I getting ahead of myself and the proposal is to modify LDP to make it so that it can still track the IGP when IP FRR is used?) Ben > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, May 18, 2005 10:47 AM > To: mpls@ietf.org > Subject: [mpls] moving discussion to the mpls working group list >=20 >=20 > MPLS working group, >=20 > there has been a discussion on the rtgwg mailing list on=20 > possible extension to LDP for finding out the next-next-hop=20 > label mapping. Possible applications for this functionality=20 > world be fast reroute. Since the extensions to the LDP should=20 > be handled by the MPLS working group, this mail is to=20 > indicate that the discussion will be contiuned on the MPLS=20 > working group list. >=20 > The non-MPLS part of this discussion will remain on the rtgwg=20 > mailing list. >=20 > This is the content of the last mail on the rtgwg thread > called "Re: the shen-mpls-nnhop Was:(Re: thoughts on=20 > draft-bryant-shand-ipfrr-notvia-addresses-00.txt)" >=20 > /Loa >=20 >=20 > Naiming and Stewart, >=20 > you wrote - and I guess this is valid: >=20 > Naiming Shen wrote: >=20 > > I think the needs start emerging, any important services > > riding on top of IP/MPLS transport infrastructure needs > > fast convergence services. It's not reasonable to assume > > only RSVP-TE LSPs need fast reroute, and other > > network transport does not. This nnhop-ldp draft is to > > facilitate the LDP based MPLS network for FRR with > > node protection. I have been talking to some providers > > in the past year, there are certainly interests in > > this service. >=20 >=20 >=20 > Stewart Bryant wrote: > > > > I think the interest that we are seeing in IPFRR for LDP > > networks demonstrates the usefulness of this work. Sure > > RSVP-TE FRR exists, but some customers have expressed > > an interest in a solution that does not use RSVP. > > >=20 > However the MPLS working group need to take a decision if, > when and how this functionality should be developed. >=20 >=20 > The way of doing this would be >=20 > - write down the requirements > - send them to the mpls wg > - we go through the moces to establish the mpls wg consensus >=20 > Comments: >=20 > - I don't think FRR for LDP based MPLS enabled IP networks > should not go into the rtgwg, the charter of the rtgwg seems > to say the rtgwg takes of everything that does not fit into > other routing are working groups (Alex and Bill comments on this?) >=20 > - my take is that for this purpose you could either document > the requirements in a separate document or put them into one > the existing documents. I've no preferences, but this should > be rather short. >=20 > - my preference would be to speed this up so we could have > a decision going into the Paris meeting. >=20 > Also I think it will be right to take this discussion to the=20 > mpls wg list. I will write a mail to mpls list to that effect. >=20 >=20 > /Loa >=20 >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 18 10:12:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPHK-0006Bj-HG; Wed, 18 May 2005 10:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPHJ-0006AE-41 for mpls@megatron.ietf.org; Wed, 18 May 2005 10:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23857 for ; Wed, 18 May 2005 10:12:02 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYPYG-0000Q3-3M for mpls@ietf.org; Wed, 18 May 2005 10:29:37 -0400 Received: from aatlas-lt.avici.com (b2-pc69.avici.com [10.2.100.69]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j4IEBjnm031070; Wed, 18 May 2005 10:11:46 -0400 Message-Id: <5.1.0.14.2.20050518100549.01fcc528@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 May 2005 10:11:45 -0400 To: benjamin.niven-jenkins@bt.com From: Alia Atlas Subject: RE: [mpls] moving discussion to the mpls working group list In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Ben, The IP FRR work applies as well to LDP. There are a couple aspects for LDP that may require additional work or investigation so that the same methods used for IP FRR will apply to LDP. This has come up on the rtgwg because of the discussion of possible work to support the more advanced (and contentious :-) methods for IP FRR. For LDP FRR, there are possible restrictions on modes & the need to advertise label bindings to all ones neighbors - not merely those that are the primary next-hops. The latter is a good idea, anyway, for convergence, and already in the RFC. For the modes, I've mostly focused on the Downstream Unsolicited with liberal label retention. If there is interest in other modes for the LDP FRR work, that'd be interesting to hear. Alia At 06:42 AM 5/18/2005, benjamin.niven-jenkins@bt.com wrote: >Loa, Colleagues, > >I have not been following the rtgwg and I can not find any drafts on LDP >next-next-hop so apologies if my questions have already been addressed. > > >My understanding is that the path LDP uses for a flow 'tracks' the IGP >and an LDP flow will take the same path through the network as an IP >flow to the same destination/FEC (assuming ECMP is not running). > >Therefore is there really a need for LDP FRR as well as IP FRR, when LDP >tracks the IGP anyway? (Or am I getting ahead of myself and the proposal >is to modify LDP to make it so that it can still track the IGP when IP >FRR is used?) > >Ben > > > -----Original Message----- > > From: mpls-bounces@lists.ietf.org > > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson > > Sent: Wednesday, May 18, 2005 10:47 AM > > To: mpls@ietf.org > > Subject: [mpls] moving discussion to the mpls working group list > > > > > > MPLS working group, > > > > there has been a discussion on the rtgwg mailing list on > > possible extension to LDP for finding out the next-next-hop > > label mapping. Possible applications for this functionality > > world be fast reroute. Since the extensions to the LDP should > > be handled by the MPLS working group, this mail is to > > indicate that the discussion will be contiuned on the MPLS > > working group list. > > > > The non-MPLS part of this discussion will remain on the rtgwg > > mailing list. > > > > This is the content of the last mail on the rtgwg thread > > called "Re: the shen-mpls-nnhop Was:(Re: thoughts on > > draft-bryant-shand-ipfrr-notvia-addresses-00.txt)" > > > > /Loa > > > > > > Naiming and Stewart, > > > > you wrote - and I guess this is valid: > > > > Naiming Shen wrote: > > > > > I think the needs start emerging, any important services > > > riding on top of IP/MPLS transport infrastructure needs > > > fast convergence services. It's not reasonable to assume > > > only RSVP-TE LSPs need fast reroute, and other > > > network transport does not. This nnhop-ldp draft is to > > > facilitate the LDP based MPLS network for FRR with > > > node protection. I have been talking to some providers > > > in the past year, there are certainly interests in > > > this service. > > > > > > > > Stewart Bryant wrote: > > > > > > I think the interest that we are seeing in IPFRR for LDP > > > networks demonstrates the usefulness of this work. Sure > > > RSVP-TE FRR exists, but some customers have expressed > > > an interest in a solution that does not use RSVP. > > > > > > > However the MPLS working group need to take a decision if, > > when and how this functionality should be developed. > > > > > > The way of doing this would be > > > > - write down the requirements > > - send them to the mpls wg > > - we go through the moces to establish the mpls wg consensus > > > > Comments: > > > > - I don't think FRR for LDP based MPLS enabled IP networks > > should not go into the rtgwg, the charter of the rtgwg seems > > to say the rtgwg takes of everything that does not fit into > > other routing are working groups (Alex and Bill comments on this?) > > > > - my take is that for this purpose you could either document > > the requirements in a separate document or put them into one > > the existing documents. I've no preferences, but this should > > be rather short. > > > > - my preference would be to speed this up so we could have > > a decision going into the Paris meeting. > > > > Also I think it will be right to take this discussion to the > > mpls wg list. I will write a mail to mpls list to that effect. > > > > > > /Loa > > > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > 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 From mpls-bounces@lists.ietf.org Fri May 20 02:52:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1My-0004Up-Ns; Fri, 20 May 2005 02:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1Mv-0004Uk-B6 for mpls@megatron.ietf.org; Fri, 20 May 2005 02:52:25 -0400 Received: from web8310.mail.in.yahoo.com (web8310.mail.in.yahoo.com [202.43.219.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12517 for ; Fri, 20 May 2005 02:52:22 -0400 (EDT) Received: (qmail 19105 invoked by uid 60001); 20 May 2005 06:51:51 -0000 Message-ID: <20050520065151.19103.qmail@web8310.mail.in.yahoo.com> Received: from [195.10.167.1] by web8310.mail.in.yahoo.com via HTTP; Thu, 19 May 2005 23:51:51 PDT Date: Thu, 19 May 2005 23:51:51 -0700 (PDT) From: Krishna Chaitanya Ramineni To: mpls@ietf.org MIME-Version: 1.0 Cc: Subject: [mpls] MPLS documents X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0835100238==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0835100238== Content-Type: multipart/alternative; boundary="0-1946944017-1116571911=:16907" --0-1946944017-1116571911=:16907 Content-Type: text/plain; charset=us-ascii Hi all, I am a new member to this list.I am very happy to be a part of this list. Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS. Thanks to one and all.. Thanks & Regards, Krishna Chaitanya --------------------------------- Yahoo! Mail Stay connected, organized, and protected. Take the tour --0-1946944017-1116571911=:16907 Content-Type: text/html; charset=us-ascii
Hi all,
 
I am a new member to this list.I am very happy to be a part of this list.
 
Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS.
 
Thanks to one and all..
 
 
Thanks & Regards,
 
Krishna Chaitanya

Yahoo! Mail
Stay connected, organized, and protected. Take the tour --0-1946944017-1116571911=:16907-- --===============0835100238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0835100238==-- From mpls-bounces@lists.ietf.org Fri May 20 03:57:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2O0-0002jA-GJ; Fri, 20 May 2005 03:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2Nv-0002j2-Qk for mpls@megatron.ietf.org; Fri, 20 May 2005 03:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16944 for ; Fri, 20 May 2005 03:57:29 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ2fD-0001xF-O6 for mpls@ietf.org; Fri, 20 May 2005 04:15:26 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IGS007B83IEFG@szxga01-in.huawei.com> for mpls@ietf.org; Fri, 20 May 2005 15:59:02 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IGS004313IDS6@szxga01-in.huawei.com> for mpls@ietf.org; Fri, 20 May 2005 15:59:02 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IGS00D3N3JY2P@szxml02-in.huawei.com>; Fri, 20 May 2005 16:00:00 +0800 (CST) Date: Fri, 20 May 2005 13:25:39 +0530 From: hemanthbs Subject: RE: [mpls] MPLS documents In-reply-to: <20050520065151.19103.qmail@web8310.mail.in.yahoo.com> To: "'Krishna Chaitanya Ramineni'" , mpls@ietf.org Message-id: <006301c55d11$514fab10$0a1110ac@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0130342127==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0130342127== Content-type: multipart/alternative; boundary="Boundary_(ID_zafwf5oDMckQVXM5JNW2BQ)" This is a multi-part message in MIME format. --Boundary_(ID_zafwf5oDMckQVXM5JNW2BQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT http://mplsrc.com/ S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Krishna Chaitanya Ramineni Sent: Friday, May 20, 2005 12:22 PM To: mpls@ietf.org Subject: [mpls] MPLS documents Hi all, I am a new member to this list.I am very happy to be a part of this list. Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS. Thanks to one and all.. Thanks & Regards, Krishna Chaitanya _____ Yahoo! Mail Stay connected, organized, and protected. Take the tour --Boundary_(ID_zafwf5oDMckQVXM5JNW2BQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

 

 

http://mplsrc.com/

 

 

 

 

S.Hemanth Balaji.

Software Engineer.

Huawei Technologies India Pvt Ltd.

Bangalore, India.

 

-----Original Message-----
From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Krishna Chaitanya Ramineni
Sent: Friday, May 20, 2005 12:22 PM
To: mpls@ietf.org
Subject: [mpls] MPLS documents

 

Hi all,

 

I am a new member to this list.I am very happy to be a part of this list.

 

Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS.

 

Thanks to one and all..

 

 

Thanks & Regards,

 

Krishna Chaitanya

Yahoo! Mail
Stay connected, organized, and protected. Take the tour

--Boundary_(ID_zafwf5oDMckQVXM5JNW2BQ)-- --===============0130342127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0130342127==-- From mpls-bounces@lists.ietf.org Fri May 20 11:05:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ94X-0007bF-SA; Fri, 20 May 2005 11:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ94U-0007Xb-QC for mpls@megatron.ietf.org; Fri, 20 May 2005 11:05:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26126 for ; Fri, 20 May 2005 11:05:52 -0400 (EDT) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9Lr-0004SJ-Mn for mpls@ietf.org; Fri, 20 May 2005 11:23:52 -0400 Received: bgslc11.burtongroup.com 63.99.125.13 from 216.151.229.254 216.151.229.254 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 20 May 2005 11:05:44 -0400 Subject: Re: [mpls] MPLS documents From: Irwin Lazar To: Krishna Chaitanya Ramineni , Message-ID: In-Reply-To: <20050520065151.19103.qmail@web8310.mail.in.yahoo.com> Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1858106703==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1858106703== Content-type: multipart/alternative; boundary="B_3199431945_3630258" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3199431945_3630258 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Try the MPLS Resource Center =AD http://www.mplsrc.com/ irwin From: Krishna Chaitanya Ramineni Date: Thu, 19 May 2005 23:51:51 -0700 (PDT) To: Subject: [mpls] MPLS documents Hi all, =20 I am a new member to this list.I am very happy to be a part of this list. =20 Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS. =20 Thanks to one and all.. =20 =20 Thanks & Regards, =20 Krishna Chaitanya Yahoo! Mail Stay connected, organized, and protected. Take the tour _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --B_3199431945_3630258 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [mpls] MPLS documents Try t= he MPLS Resource Center – http://www.= mplsrc.com/

irwin



From: Krishna Chaitanya Ramine= ni <kc_413@yahoo.co.in>
Date: Thu, 19 May 2005 23:51:51 -0700 (PDT)
To: <mpls@ietf.org>
Subject: [mpls] MPLS documents

Hi all,
 
I am a new member to this list.I am very happy to be a part of this list.  
Can some one can provide me links to MPLS documents or MPLS files.I am a be= giner in MPLS.
 
Thanks to one and all..
 
 
Thanks & Regards,
 
Krishna Chaitanya
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour <http://tour.mail.yahoo.com/mailtou= r.html>
____________________= ___________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
 --B_3199431945_3630258-- --===============1858106703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1858106703==-- From mpls-bounces@lists.ietf.org Sat May 21 19:14:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZdBJ-0001D0-3f; Sat, 21 May 2005 19:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZdBG-0001Am-LT for mpls@megatron.ietf.org; Sat, 21 May 2005 19:14:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06706 for ; Sat, 21 May 2005 19:14:51 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZdSu-000607-Gu for mpls@ietf.org; Sat, 21 May 2005 19:33:09 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 May 2005 16:14:31 -0700 X-IronPort-AV: i="3.93,126,1115017200"; d="scan'208"; a="268106527:sNHT35545231144" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4LNE6mC023689; Sat, 21 May 2005 16:14:29 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 16:14:12 -0700 Received: from [192.168.1.101] ([10.21.82.8]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 16:14:12 -0700 In-Reply-To: <20050520065151.19103.qmail@web8310.mail.in.yahoo.com> References: <20050520065151.19103.qmail@web8310.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <76d80a25dd4791ea5a0e9c9b25b65ddd@cisco.com> From: JP Vasseur Subject: Re: [mpls] MPLS documents Date: Sat, 21 May 2005 19:14:24 -0400 To: Krishna Chaitanya Ramineni X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 21 May 2005 23:14:12.0549 (UTC) FILETIME=[CCC57F50:01C55E5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648034252==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0648034252== Content-Type: multipart/alternative; boundary=Apple-Mail-3-971111593 --Apple-Mail-3-971111593 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable if you're interested: =20 http://www.amazon.com/exec/obidos/tg/detail/-/1587051869/=20 qid=3D1113389463/sr=3D8-4/ref=3Dsr_8_xs_ap_i4_xgl14/102-4584797-2032940?=20= v=3Dglance&s=3Dbooks&n=3D507846 JP. On May 20, 2005, at 2:51 AM, Krishna Chaitanya Ramineni wrote: > Hi all, > =A0 > I am a new member to this list.I am very happy to be a part of this =20= > list. > =A0 > Can some one can provide me links to MPLS documents or MPLS files.I am = =20 > a beginer in MPLS. > =A0 > Thanks to one and all.. > =A0 > =A0 > Thanks & Regards, > =A0 > Krishna Chaitanya > > Yahoo! Mail > Stay connected, organized, and protected. Take the =20 > tour_______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --Apple-Mail-3-971111593 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable if you're interested: = http://www.amazon.com/exec/obidos/tg/detail/-/1587051869/qid=3D1113389463/= sr=3D8-4/ref=3Dsr_8_xs_ap_i4_xgl14/102-4584797-2032940?v=3Dglance&s=3Dbook= s&n=3D507846 JP. On May 20, 2005, at 2:51 AM, Krishna Chaitanya Ramineni wrote: Hi all, =A0 I am a new member to this list.I am very happy to be a part of this list. =A0 Can some one can provide me links to MPLS documents or MPLS files.I am a beginer in MPLS. =A0 Thanks to one and all.. =A0 =A0 Thanks & Regards, =A0 Krishna Chaitanya Yahoo! Mail Stay connected, organized, and protected. 0000,0000,EEEETake the tour_______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls = --Apple-Mail-3-971111593-- --===============0648034252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0648034252==-- From mpls-bounces@lists.ietf.org Mon May 23 07:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBKh-0001uF-UO; Mon, 23 May 2005 07:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBKg-0001ta-Fk for mpls@megatron.ietf.org; Mon, 23 May 2005 07:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16288 for ; Mon, 23 May 2005 07:42:53 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBcc-0000Zi-K3 for mpls@ietf.org; Mon, 23 May 2005 08:01:29 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j4NBcjU00578 for ; Mon, 23 May 2005 13:38:45 +0200 Received: from [127.0.0.1] ([172.16.2.216]) by mail1.imc.kth.se; Mon, 23 May 2005 13:42:38 +0200 Message-ID: <4291C1AC.2010507@pi.se> Date: Mon, 23 May 2005 13:42:36 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] working group last call on draft-ietf-mpls-p2mp-sig-requirement-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, this to initiate a working group last call on draft-ietf-mpls-p2mp-sig-requirement-02.txt Please send comments to the working group mailing list and copy wg chairs. The working group last call will end June 3rd EOB PST. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon May 23 11:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFDM-0004W7-OF; Mon, 23 May 2005 11:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFDK-0004W1-Mf for mpls@megatron.ietf.org; Mon, 23 May 2005 11:51:34 -0400 Received: from rediffmail.com (webmail10.rediffmail.com [202.54.124.179] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08124 for ; Mon, 23 May 2005 11:51:31 -0400 (EDT) Received: (qmail 22498 invoked by uid 510); 23 May 2005 15:52:42 -0000 Date: 23 May 2005 15:52:42 -0000 Message-ID: <20050523155242.22497.qmail@webmail10.rediffmail.com> Received: from unknown (202.71.142.66) by rediffmail.com via HTTP; 23 may 2005 15:52:42 -0000 MIME-Version: 1.0 From: "rehan mohammad jamadar" To: mpls@ietf.org Cc: Subject: [mpls] (no subject) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rehan mohammad jamadar List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0117567613==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multipart mime message --===============0117567613== Content-type: multipart/alternative; boundary="Next_1116863562---0-202.54.124.179-22489" This is a multipart mime message --Next_1116863562---0-202.54.124.179-22489 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0i want to know abt mpls network and its configuration details so pls ma= il me=0A --Next_1116863562---0-202.54.124.179-22489 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A  i want to know abt mpls network and its configuration details = so pls mail me
=0A=0A

=0A

=0A=0A --Next_1116863562---0-202.54.124.179-22489-- --===============0117567613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0117567613==-- From mpls-bounces@lists.ietf.org Thu May 26 03:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbCo6-0004IM-4e; Thu, 26 May 2005 03:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbCo1-0004I9-Tt for mpls@megatron.ietf.org; Thu, 26 May 2005 03:29:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05877 for ; Thu, 26 May 2005 03:29:24 -0400 (EDT) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbD6Z-0001Hg-HD for mpls@ietf.org; Thu, 26 May 2005 03:48:36 -0400 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DbCo0-000F2d-1u; Thu, 26 May 2005 08:29:24 +0100 From: "Adrian Farrel" To: mpls@ietf.org Date: Thu, 26 May 2005 08:29:23 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.84 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] draft-ietf-mpls-rsvpte-attributes-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, I have submitted a new revision of this draft. The following changes were made to address specific comments made during IESG review and during discussions with the IESG. Thanks, Adrian Mike Shand commented... > > 1) In section 3, under length, it says that the padding > > to take the value field up to a 4 byte boundary is NOT > > included in the length. > > However in section 3.1 para 3 it says that the length > > field is always a multiple of 4 bytes regardless of the > > number of bits set. > > > > I'm having difficulty reconciling those two statements. After discussion, Mike suggested... > "The Attribute Flags TLV value field is an array of a > multiple of 32 flags numbered from the MSB as bit zero. > The length field for this TLV is therefore always a > multiple of 4 bytes, regardless of the number of bits > carried and no padding is required." We have added this text to section 3.1. > > 2) The TLV defined above in section 3 is of the normal > > design in that the length is the length of the value > > field only and does not include the type and length > > fields. However, the TLV defined 7.2 has a different > > form where the length includes the type and length > > fields. > > > > Is there some rationale why the same protocol uses both > > types of encoding? After discussion, we agreed to make no changes because the TLV definition in section 3 is "normal" and it is the prefered way to define TLVs for the new object. The "TLV" in section 7.2 is not actually a TLV but is a sub-object according to the definitions and format in RFC3209. We have no scope to play with this definition. > > And one final question. In section 9 it says in paras > > 5 and 7 that LSRs SHOULD be prepared to receive this > > object in any order.... > > > > should that be a MUST, or is SHOULD acceptable? It would > > appear to be non-optional. This is correct, and the text has been changed to 'MUST'. Mike also pointed out a couple of typos which have been fixed. Joel Halpern raised the following points. > > IANA Considerations: > > The document identifies two new spaces for the IANA to > > manage. It lists the properties of relevance to values > > in these spaces. However, it does not indicate what > > procedure is to be followed for assigning values in > > these registries. Are they to be assigned only by > > IETF Standards Track RFCs? Are they assigned simply > > on a first-come, first-served basis with sufficient > > documentation? We have added to section 11.3 "New bit numbers may be allocated only by an IETF Consensus action." And to section 11.4 "It is suggested that new SESSION_ATTRIBUTE Flags be allocated only by an IETF Consensus action." > > The document talks about several degrees or kinds of > > mandatory / optional information, ranging from > > information that must be examined at every node to > > information that only needs to be examined at the > > end-points. The specific example is given of information > > that needs to be examined at ABR/ASBRs, but should be > > deployable without upgrading all routers in the path. > > It is not clear that this stated goal is met by the > > solution provided. Some text on how the various cases > > listed are met by the documented method would be > > helpful. After refining the requirements with Joel, we have added section 10 and its subsections. > > In section 7.3.1, there are two lines which confused me: > > The Attributes subobject is pushed onto the > > RECORD_ROUTE object immediately prior to pushing the > > node's IP address or link > > ... > > This means that an Attributes subobject is bound to > > the LSR identified by the subobject found in the RRO > > immediately before the Attributes subobject. > > > > The first sentence seems to say that when I parse the > > message I will find the Attributes subobject followed > > by the ID of the node which put it there. The later > > sentence seems to say that the Attributes subobject is > > bound to the ID which precedes it, rather than the ID > > which follows it? We discussed this point and agreed that the RRO is described as a stack. So, that which you push first, you pop last. You receive an RRO and you add your sub-objects to the front. You add the Attributes sub-object first, then you add your node/link. We clarified the text in 7.3.1 by replacing < The Attributes subobject is pushed onto the RECORD_ROUTE < object immediately prior to pushing the node's IP address < or link identifier. Thus, if label recording is being used, < the Attributes subobject SHOULD be pushed onto the < RECORD_ROUTE object after the Record Label subobject(s). with > As will be clear from [RFC3209], the RECORD_ROUTE object > is managed as a "stack" with each LSR adding sub-objects > to the start of the object. The Attributes subobject is > pushed onto the RECORD_ROUTE object immediately prior to > pushing the node's IP address or link identifier. Thus, > if label recording is being used, the Attributes subobject > SHOULD be pushed onto the RECORD_ROUTE object after the > Record Label subobject(s). Mark Townsley made a series of useful editorial comments. At the send of section 1 it says... >> This document distinguishes between options and attributes >> that are only required at key LSRs along the path of the >> LSP, and those that must be acted on by every LSR along >> the LSP. Two LSP Attributes objects are defined in this >> document: the first may be passed transparently by LSRs >> that do not recognize it, the second must cause LSP setup >> failure with the generation of a PathErr message with an >> appropriate Error Code if an LSR does not recognize it. > > "must" cause or "will" cause. Must (even without capital > letters) implies that this is new functionality, > though I think this is a statement about existing > functionality. Mark is quite right, this is existing functionality. In order to clarify this, the text is changed to read... This document distinguishes between options and attributes that are only required at key LSRs along the path of the LSP, and those that must be acted on by every LSR along the LSP. Two LSP Attributes objects are defined in this document: using the C-Num definition rules inherrited from [RFC2205], the first is passed transparently by LSRs that do not recognize it, and the second causes LSP setup failure with the generation of a PathErr message with an appropriate Error Code if an LSR does not recognize it. >> 1.1 Applicability to Generalized MPLS >> >> The RSVP-TE signaling protocol also forms the basis of a >> signaling protocol for Generalized MPLS (GMPLS) as >> described in [RFC3471] and [RFC3473]. The extensions >> described in this document are intended to be equally >> applicable to MPLS and GMPLS. > > Are they "intended" to be applicable to both, or is this > document actually defining them to be applicable to both? >> 3. Attributes TLVs >> >> [snip] >> >> Length >> >> The length of the value field in bytes. Thus if no value >> field is present the length field contains the value zero. >> Each value field must be zero padded at the end to take it >> up to a four byte boundary - the padding is not included in >> the length so that a one byte value would be encoded in an >> eight byte TLV with length field set to one. > > The padding here seems unnecessarily complex. I am left to > wonder whether a 4 byte Value field should have a Length of > 1, 2, 3 or 4 (or any of the above). Personally, I think any > word-alignment gains achieved by forcing the Value to be > divisible by 4 here are outweighed by the interoperability > overhead necessary to ensure that this is interpreted > correctly by all parties. These padding rules are not uncommon in RSVP, and there seems no reason not to continue to use them. The authors feel that the descriptive text and the example make the meaning quite clear. >> 3.1 Attributes Flags TLV >> >> This document defines only one TLV type value. Type 1 >> indicates the Attributes Flags TLV. Other TLV types may >> be defined in future with type values assigned by IANA. > > A direct reference to the IANA consideration section that > deals with this would be nice here. A reference has been added. >> [snip] >> >> Unassigned bits are considered as reserved and MUST be >> set to zero on transmission by the originator of the >> object. Bits not contained in the TLV MUST be assumed >> to be set to zero. If the TLV is absent either because >> it is not contained in the LSP_ATTRIBUTES or >> LSP_REQUIRED_ATTRIBUTES object, or because those objects >> are themselves absent, all processing MUST be performed >> as though the bits were present and set to zero. > > Would it be simpler and sufficient just to say that > unassigned bits are set to zero on transmission and > ignored upon receipt? This comment has missed the point. It is true that unassigned bits MUST be set to zero on transmission as the text says. However, the text continues to describe *assigned* bits that are not present either because the TLV is deliberatley forshortened, or because the TLV is not included. In these cases the receiver MUST act (as described by the text) as though the assigned bits are set to zero. The text has been clarified further. >> [snip] >> >> No bits are defined in this document. The assignment >> of bits is managed by IANA. > > Again, a direct reference to IANA would be nice. Reference added. >> 5. LSP_REQUIRED_ATTRIBUTES Object >> >> The LSP_REQUIRED_ATTRIBUTES object is used to signal >> attributes required in support of an LSP, or to >> indicate the nature or use of an LSP where that >> information MUST be inspected at each transit LSR. >> Specifically, each transit LSR MUST examine the >> attributes in the LSP_REQUIRED_ATTRIBUTES object and >> MUST NOT forward the object transparently. > > If, after examination of the attribute at the LSR, it is > determined that the object should be forwarded > transparently, is that a protocol violation? Probably not, > though the text above might spark such a debate. We had a jolly time debating the meaning of the word 'transparent'. In order to spare us another such discussion the text has been modified to read as follows... The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information MUST be inspected at each transit LSR. Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object without acting on its contents. >>[snip] >> >> There is a one-to-one correspondence between bits in the >> Attributes Flags TLV and the RRO Attributes Subobject. If >> a bit is only required in one of the two places, it is >> reserved in the other place. See the procedures sections, >> below, for more information. >> >> 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 | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> // Attribute Flags // >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I don't understand the advantage of creating a subobject TLV > format with one-byte Type and Length here, particularly given > that the Value is the same number-space as the Main TLV. Why > not just use the same TLV format and rules that have already > been defined? Is there some intended used of the Reserved field > or desire to keep the Type field small? After some discussion, we agreed that keeping the same subobject format as all of the other subobjects in the RRO was likely to increase the chance of the RRO being successfully parsed and would probably be beneficial for backwards compatibility. >> 7.3.1 Subobject Presence Rules >> >> [snip] >> >> If the new subobject causes the RRO to be too big to >> fit in a Path (or Resv) message, the processing MUST >> be as described in [RFC3209]. > > A quick summary of what this means, or section within 3209 > would be a nice gesture for the reader. The authors are always happy to gesture to the reader, and have added a reference to section 4.4.3 of RFC 3209. >>7.3.2 Reporting Compliance with LSP Attributes >> >> To report compliance with an attribute requested in the >> Attributes Flags TLV, an LSR MAY set the corresponding >> bit (see Section 8) in the Attributes subobject. To >> report non-compliance, an LSR MAY clear the corresponding >> bit in the Attributes subobject. >> >> The requirement to report compliance MUST be specified in >> the document that defines the usage of any bit. This will >> reduce to a statement of whether hop-by-hop acknowledgement >> is required. > > So, each implementation will have to keep a list of which bits > it should react to, and which it shouldn't? This seems to be > rife with interop headaches. Why not just mandate the MUST here > and force the follow-on documents to inherit this? Or, split > the bits into different attributes (hop-by-hop or not > hop-by-hop)? Since each implementation will have to keep a list of what it has to do for each bit, this is nothing special. No change is made to the document. >> 11.3 Attributes Flags >> >> [snip] >> >> IANA is requested to manage the space of attributes bit flags >> numbering them in the usual IETF notation starting at zero and >> continuing through 2039. > > So, there are up to 2039 individual bits allowed? Isn't that a bit > of overkill? No, that would be 2040 bits. But the text should read 31. John Loughney added some further review comments >> Major comment is that I find the IANA section inadequate. >> It seems to be introducing a new namespace for IANA to take >> care of, but no rules on how new values are allocated. It >> seems to indicate that an RFC number is needed in section >> 10.3, but I think this needs to be more specific. The text >> in other places of the document are not so clear at what >> constitues a reason for allocating new bit flags, etc., >> so in the IANA section, I think there needs to be explicit >> text on the the mechanisms for specifying and definting them. We believe that this issue is addressed by the changes to the IANA sections already discussed. > 1) Way too much acronyms in the abstract ... Well, there are five. Each is expanded on first usage. This doesn't seem unreasonable to us. > 2) Took me several reads to be able to parse the following > text: > >> .... Because of the nature of the TLV >> construction the object is flexible and allows the future >> definition of: >> - further bit flags if further, distinct uses are discovered >> - arbitrary options and attributes parameters carried as >> individual TLVs. > >suggest: > > The new RSVP-TE message object is quite flexible, due to > the use of the TLV format and allows: > - future specification of bit flags > - additional options and atttribute paramerters carried > in TLV format. New text used. > 3) This text was confusing: > >>4.2 Generic Processing Rules for Path Messages >> >> An LSR that does not support this object will pass it on >> unaltered because of the C-Num. > >suggest: > >4.2 Generic Processing Rules for Path Messages > > An LSR that does not support this object is required to pass > it on unaltered, as the C-Num indicates that the LSR should > pass the object on transparently. In order not to get into another discussion of the meaning of the word 'transparent' we have settled on the following text.. An LSR that does not support this object is required to pass it on unaltered as indicated by the C-Num and the rules defined in [RFC2205]. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 26 03:58:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbDGB-00014X-KW; Thu, 26 May 2005 03:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbDG8-00014M-NZ for mpls@megatron.ietf.org; Thu, 26 May 2005 03:58:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08224 for ; Thu, 26 May 2005 03:58:26 -0400 (EDT) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbDYf-00025l-HC for mpls@ietf.org; Thu, 26 May 2005 04:17:38 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id j4Q7s5U32087 for ; Thu, 26 May 2005 09:54:05 +0200 Received: from [127.0.0.1] ([172.16.2.216]) by mail1.imc.kth.se; Thu, 26 May 2005 09:58:05 +0200 Message-ID: <4295817D.9000909@pi.se> Date: Thu, 26 May 2005 09:57:49 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, Naiming Shen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] question/comments draft-shen-mpls-ldp-nnhop-label-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Naiming, after reading the draft-shen-mpls-ldp-nnhop-label-02.txt I've a few hopefully smaller questions on the draft for my own understanding - if an upstream LSR sends a "next hop mapping request" to a downstream neighbor what will the effect be -- that the downstream neighbor sends all existing nnhop mappings back or that he downstream neighbor sends nnhop mapping s for all future label mappings - is there a way to ask for a specific nnhop label mapping? - since there might several mappings for labels between the downstream and the nnhop, how does the upstream pick the right one? - the FRR tunnels in your picture does not seem to follow routing, how was it established? /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 26 15:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOLz-0001gl-33; Thu, 26 May 2005 15:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOLu-0001g4-Rh; Thu, 26 May 2005 15:49:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27606; Thu, 26 May 2005 15:49:08 -0400 (EDT) Message-Id: <200505261949.PAA27606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 26 May 2005 15:49:08 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvpte-attributes-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart 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 : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-rsvpte-attributes-05.txt Pages : 20 Date : 2005-5-26 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE). This protocol includes an object (the SESSION_ATTRIBUTE object) which carries a flags field used to indicate options and attributes of the LSP. That flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-05.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-rsvpte-attributes-05.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-rsvpte-attributes-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-26162009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvpte-attributes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvpte-attributes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26162009.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Fri May 27 06:33:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbc9P-0000bG-8S; Fri, 27 May 2005 06:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbc9M-0000Zt-Md for mpls@megatron.ietf.org; Fri, 27 May 2005 06:33:08 -0400 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28300 for ; Fri, 27 May 2005 06:33:06 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 68so705951wri for ; Fri, 27 May 2005 03:32:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Uzj1dUZEA95evijAGXuhFQSE01nYUeoRpN6cBLgZplVyaC8wegQus8LIn5eMV6QAeOcm85Swj1aEHqXiIDrj0mJI4eQ1Rax6Q5GYifT6udOvc4xHYKkfzGgr0fXn0W76m8wo60J0UUbCgRAdkL7feZzdeAl8lpCAR1WV8P+3zUM= Received: by 10.54.23.26 with SMTP id 26mr1531458wrw; Fri, 27 May 2005 03:32:37 -0700 (PDT) Received: by 10.54.40.26 with HTTP; Fri, 27 May 2005 03:32:37 -0700 (PDT) Message-ID: Date: Fri, 27 May 2005 18:32:37 +0800 From: Bob Anders To: mpls@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] Non-Standard use of MPLS X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Anders List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Dear MPLS-Experts, I am aware that MPLS is intended to be used for switching purposes, but I was wondering if anyone knows about implementations or plans that make use of MPLS in a non-standard way, like - MPLS is still used to make forwarding decisions, but the stack contains also non-forwarding relevant information either in Exp bits or in separate labels (type of information possibly identified by Exp bits) Or - The MPLS stack is only used as a "vehicle" to encode additional non-forwarding relevant information. Forwarding decisions are still based on the underlying protocol (e.g. IPv4). When talking about non-forwarding relevant data, I am thinking of information used for encryption, network statistics, billing, etc ... If there is anything out there (or maybe planed by IETF or whoever) that makes use of MPLS-like stacks as described above, I would be happy to hear about it (URLs, papers, ...). Thanks and have a nice weeked! Bob _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 27 08:02:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbdY7-0006Kw-9D; Fri, 27 May 2005 08:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbdY5-0006Kn-L2 for mpls@megatron.ietf.org; Fri, 27 May 2005 08:02:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03992 for ; Fri, 27 May 2005 08:02:44 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbdqr-0000vX-Ua for mpls@ietf.org; Fri, 27 May 2005 08:22:11 -0400 Received: from default.mail.com (c-24-61-134-169.hsd1.ma.comcast.net[24.61.134.169]) by comcast.net (sccrmhc14) with SMTP id <2005052712023501400qke7oe>; Fri, 27 May 2005 12:02:35 +0000 Message-Id: <6.2.1.2.2.20050527075809.06d94350@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 27 May 2005 08:02:32 -0400 To: Bob Anders From: "Andrew G. Malis" Subject: Re: [mpls] Non-Standard use of MPLS In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.6 (+++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Bob, The PWE3 working group has defined a non-IP-forwarding use for the innermost label on the stack - it identifies a logical or physical layer 1 or layer 2 port on a router, plus optionally a layer 2 multiplexing tag or label (FR DLCI, Ethernet VLAN tag, ATM VPI/VCI, etc.). This mechanism is also used by the L2VPN working group for VPLS and other layer 2 VPNs over MPLS. Cheers, Andy ---------- At 5/27/2005 18:32 +0800, Bob Anders wrote: >Dear MPLS-Experts, > >I am aware that MPLS is intended to be used for switching purposes, >but I was wondering if anyone knows about implementations or plans >that make use of MPLS in a non-standard way, like > >- MPLS is still used to make forwarding decisions, but the stack >contains also non-forwarding relevant information either in Exp bits >or in separate labels (type of information possibly identified by Exp >bits) >Or >- The MPLS stack is only used as a "vehicle" to encode additional >non-forwarding relevant information. Forwarding decisions are still >based on the underlying protocol (e.g. IPv4). > >When talking about non-forwarding relevant data, I am thinking of >information used for encryption, network statistics, billing, etc ... > >If there is anything out there (or maybe planed by IETF or whoever) >that makes use of MPLS-like stacks as described above, I would be >happy to hear about it (URLs, papers, ...). > >Thanks and have a nice weeked! > > Bob > >_______________________________________________ >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 From mpls-bounces@lists.ietf.org Fri May 27 10:10:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfYA-0001Du-Ug; Fri, 27 May 2005 10:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfY8-0001DG-B7 for mpls@megatron.ietf.org; Fri, 27 May 2005 10:10:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14281 for ; Fri, 27 May 2005 10:10:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbfqv-00046k-3X for mpls@ietf.org; Fri, 27 May 2005 10:30:22 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j4REAi2c022233 for ; Fri, 27 May 2005 10:10:44 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18834 for ; Fri, 27 May 2005 10:10:44 -0400 (EDT) Message-ID: <42972A63.8040101@marconi.com> Date: Fri, 27 May 2005 10:10:43 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] Non-Standard use of MPLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Bob Anders wrote: > > - MPLS is still used to make forwarding decisions, but the stack > contains also non-forwarding relevant information either in Exp bits > or in separate labels (type of information possibly identified by Exp > bits) This is done already for certain features. EXP bits are used to encode priority levels in E-LSPs. Non-forwarding labels are used to identify VPNs (PWE3) and to identify the payload-type for layer-2 traffic (Martini). > - The MPLS stack is only used as a "vehicle" to encode additional > non-forwarding relevant information. Forwarding decisions are still > based on the underlying protocol (e.g. IPv4). I'm pretty sure that this would violate quite a number of RFCs. If an MPLS router receives labeled traffic, it is supposed to forward that traffic according to its label. If you need to tack additional information onto non-MPLS traffic, there are mechanisms for doing so, including options in the IP header and various kinds of IP-in-IP encapsulation. > When talking about non-forwarding relevant data, I am thinking of > information used for encryption, network statistics, billing, etc ... WRT MPLS, this information is probably best propagated by the signaling stack. Adding (possibly new) objects to Path and Resv messages works well for propagating information between the connection endpoints. When combined with some form of per-LSP traffic counter, you should get all the information you need without having to alter the data-plane traffic at all. Of course, your specific application requirements would dictate the best approach. -- David _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 27 10:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfyh-00071f-VS; Fri, 27 May 2005 10:38:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbfyg-0006yx-3x for mpls@megatron.ietf.org; Fri, 27 May 2005 10:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17198 for ; Fri, 27 May 2005 10:38:20 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgHS-0004hN-13 for mpls@ietf.org; Fri, 27 May 2005 10:57:49 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.50) id 1DbfyQ-000801-QY for mpls@ietf.org; Fri, 27 May 2005 10:38:06 -0400 Received: from 65.213.193.37 ([65.213.193.37]) by isocore.com (Horde) with HTTP for ; Fri, 27 May 2005 10:38:06 -0400 Message-ID: <20050527103806.113az8e8b28004gk@isocore.com> Date: Fri, 27 May 2005 10:38:06 -0400 To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] CFP: MPLS 2005 (Oct 16-19, Washington, DC) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org CONFERENCE: MPLS 2005 International Conference URL: www.mpls2005.com DATE: October 16-19, 2005 LOCATION: Washington, DC DEADLINE FOR CALL FOR PARTICIPATION IS APPROACHING: JUNE 10, 2005 The Program Committee of MPLS2005 is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker's contact details to the attention of the Technical Program Committee at mpls2005-cfp@isocore.com by June 10, 2005. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider, research and user community are solicited on new technologies and operational experience. This year's conference will include, but not be limited to, topics such as: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Supporting multicast in MPLS VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in the Next Generation Network - Voice over IP/MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Testing the technology: MPLS test tools and experience - Protection, restoration and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - Motivations and requirements for extending MPLS into the access network ============================================================= ALSO NOTE: Registration for the conference is open - substantial discounts are available for early registration. Visit for details. ============================================================= _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 27 13:35:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbijy-0003ro-KB; Fri, 27 May 2005 13:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbijw-0003rj-5X for mpls@megatron.ietf.org; Fri, 27 May 2005 13:35:20 -0400 Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01300 for ; Fri, 27 May 2005 13:35:16 -0400 (EDT) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4RHXWL15875; Fri, 27 May 2005 10:33:32 -0700 (PDT) Message-Id: <200505271733.j4RHXWL15875@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 27 May 2005 10:33:32 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4090 on Fast Reroute Extensions to RSVP-TE for LSP Tunnels X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4090 Title: Fast Reroute Extensions to RSVP-TE for LSP Tunnels Author(s): P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed. Status: Standards Track Date: May 2005 Mailbox: ppan@hammerheadsystems.com, swallow@cisco.com, aatlas@avici.com Pages: 38 Characters: 83965 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4090.txt This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050527103211.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4090 --OtherAccess Content-Type: Message/External-body; name="rfc4090.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050527103211.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue May 31 15:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCnF-0007qL-Hb; Tue, 31 May 2005 15:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdCnB-0007oq-9l; Tue, 31 May 2005 15:52:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13028; Tue, 31 May 2005 15:52:47 -0400 (EDT) Message-Id: <200505311952.PAA13028@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 31 May 2005 15:52:47 -0400 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-nodeid-subobject-06.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart 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 : Definition of an RRO node-id subobject Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-nodeid-subobject-06.txt Pages : 9 Date : 2005-5-31 In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switch Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an IGP area or an Autonomous System. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-domain TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-06.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-nodeid-subobject-06.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-nodeid-subobject-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-31155747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-nodeid-subobject-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-31155747.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Jun 01 08:08:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdS1P-0001ey-9N; Wed, 01 Jun 2005 08:08:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd98y-0008E0-13; Tue, 31 May 2005 11:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20935; Tue, 31 May 2005 11:59:01 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd9Sa-0005VF-V9; Tue, 31 May 2005 12:19:22 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j4VFvVpF009435; Tue, 31 May 2005 10:57:32 -0500 (CDT) Received: from earth.dnrc.bell-labs.com (earth.dnrc.bell-labs.com [135.180.160.88]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j4VFvOs16826; Tue, 31 May 2005 11:57:27 -0400 (EDT) Date: Tue, 31 May 2005 11:57:24 -0400 (EDT) From: Thyaga Nandagopal X-X-Sender: thyaga@earth.dnrc.bell-labs.com To: srajeev@in.ibm.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail1.lucent.com id j4VFvVpF009435 X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 01 Jun 2005 08:08:28 -0400 Cc: Subject: [mpls] Deadline approaching: CONSWARE 2006 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on=20 Communication Systems Software and Middleware http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor : IEEE Communications Society=20 In Co-operation with : ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA) Co-Sponsors: IBM, Microsoft Research, NOKIA,=20 Lucent Technologies, Sasken University Co-Sponsor: Indian Institute of Technology, Delhi Paper Submission: June 4, 2005 =20 (Instructions at http://www.comsware.org) (Proceedings to be published by IEEE and to appear in IEEE=20 Explore) The convergence of the communications, information technologies and the=20 Internet has ushered in a revolution in the way people communicate with each other= .=20 The key enabler for this convergence has been the advancement of software=20 technology in various communication sectors, as evident by the high levels of activity=20 in the industry, academia, and standards bodies, coupled with the increasing=20 dependence of this convergence to sustain and improve growth rates in many countries=20 around the world. This new international conference will provide a forum to exchange ideas,= =20 techniques, and applications, discuss best practices and challenging issues, raise=20 awareness and share experiences among researchers, practitioners, standard developers=20 and policy makers in the field of software techniques in communications. The=20 conference will bring leading researchers and practitioners in areas ranging from=20 communications software and software engineering aspects of communications software, to=20 middleware and networking protocols. The objective of the conference is to provide a= =20 high degree of collaboration, participation and discussions of the various=20 topics among multi-national participants from the industrial, governmental and academi= c=20 sectors. COMSWARE will include a regular paper track and an industry track. The=20 paper track will include a highly selective technical program. The conference solicit= s=20 original, previously unpublished research work, experimental efforts, and practical= =20 experiences for the technical program. COMSWARE will also feature panel discussions=20 from experts in academia and industry, workshops and tutorials featuring the=20 state-of-the-art in various communications software and related areas. There will be demos an= d=20 exhibits that will expose the delegates to exciting products and software solution= s=20 from industry and academia. Accepted papers will be published by IEEE Computer= =20 Society. The top papers accepted to the conference will be published in a reputed=20 journal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems=20 =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 4, 2005 (Instructions at http://www.comsware.org) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs: Victor Bahl, Microsoft Research, USA Bijendra Nath Jain, IIT, Delhi, India Henning Schulzrinne, Columbia University, USA Alfred Spector, IBM Research, USA Steering Committee: Imrich Chlamtac, University of Trento, Italy =20 (Chair) Rajeev Shorey, IBM Research, India =20 (Co-Chair) Prasant Mohapatra, University of California,=20 Davis, USA=20 =20 (Co-Chair) =20 Program Chairs: Sanjoy Paul, Whenu, USA G. Venkatesh, SASKEN Technologies, India Jim Woodcock, University of York, UK Tutorial Chair: Archan Misra, IBM Research, USA Workshop Chairs: Ashwin Gumaste, Fujitsu Research, USA Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Co-Chairs: Sudipta Maitra, IBM, Delhi Laurent Mignet, IBM Research, Delhi _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls