The MPLS WG Archive

["M. elk" <elkou141061@hotmail.com>]

 

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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls