The MPLS WG Archive

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

 

N.B: Sorry , have to partition part 2/3 further into First particle and 2nd particle  

 

Part 2 of 3 - 2nd Particle  

 

 

Appreiate the clarification :

 

   

 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 .

 

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

 

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

 

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

  

 

 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 <RSC> is included/populated  it is mandatory to include this

               TLV in the echo reply.  

 

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

 

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

 

Brgds

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