Subject: [mpls] Clarfication reg LSP PING - Draft ver 08-Part 1/3 .

From: "M. elk" <[email-masked]>
Date: Mon, 2 May 2005 14:23:02 +0300

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 ,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 .

    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 . 

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 . 
      
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 .

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 .
        
 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 .

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  )  .

      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 ???

Brgds 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls