Subject: signaling in draft-kompella-mpls-bundle-04.txt

From: Fong Liaw <[email-masked]>
Date: Fri, 16 Feb 2001 19:04:33 -0800

Hi Lou, 

I have a question regarding why the bundled draft
specifies both upstream and downstream component link
while GMPLS draft assumes the same link is used for
both upstream and downstream LSP. I believe the GMPLS
model make more sense.

If we are going to assume the same link should be
used for both upstream and downstream LSP, we really
do not need the new component link identifier object 
since the RSVP HOP object already has the ability to 
identify a local (component) index along with an 
IP address.

Thanks.
-Fong

---

From: Fong Liaw <[email-masked]>
Date: Tue, 20 Feb 2001 11:58:23 -0800

Hi, Adrian

Thanks for replying.

My question is really "if a component link 
of a bundled link may be uni-directional, then
a regular link may also be uni-directional and 
we also need an (upstream link) object in ERO (or somewhere). 
Bundle is a method of aggregation, it should not change the 
fundamental of link selection." Is this logic flaw somewhere ?

Also, the (new) component_interface_ID also requires the 
other node to know what the (sender) remote ID as well, 
using LIH to mean component_interface_ID, by agreement for GMPLS, 
would be a fine approach. This is a minor point, I am fine 
with a different object if most people feel the a new object 
is needed.

Regards,
-Fong

>  -----Original Message-----
>  From: Adrian Farrel [mailto:[email-masked]]
>  Sent: Tuesday, February 20, 2001 10:39 AM
>  To: Zaffire - Fong Liaw; [email-masked]'
>  Cc: [email-masked]'
>  Subject: RE: signaling in draft-kompella-mpls-bundle-04.txt
>  
>  
>  Fong,
>  
>  The point with LIH in RSVP_HOP is that it identifies the 
>  link from the
>  sender perspective.  (NB, it is not really GMPLS, it is base RSVP).
>  
>  What Kireeti has described in the bundling draft is the 
>  ability to have
>  multiple component links of a single link.  Clearly when the 
>  Path message is
>  sent (e.g. on a control channel) the downstream node must be 
>  able to work
>  out which component link is going to be used for the data.  
>  The LIH cannot
>  be used since it provides the sender's identifier for the 
>  link and may have
>  no meaning to the receiver.  Hence a new object is introduced.
>  
>  Now turning to bi-directional LSPs.  The component links in 
>  a bundle are
>  quite possibly uni-directional.  If they are, they may be 
>  paired so that you
>  could consider one component link to be built from one 
>  forward and one
>  reverse link, but there is no reason why this should be the case.
>  
>  So you need to identify the component links that will be 
>  used for each
>  direction on the LSP.  Hence the two objects in the bundling draft.
>  
>  Hope this helps.
>  Adrian
>  
>  --
>  Adrian Farrel  mailto:[email-masked]
>  Network Convergence Group
>  Data Connection Ltd., Chester, UK
>  http://www.dataconnection.com/
>  Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>  
>  
>  >-----Original Message-----
>  >From: Zaffire - Fong Liaw 
>  >Sent: Saturday, February 17, 2001 3:05 AM
>  >To: [email-masked]'
>  >Cc: [email-masked]'
>  >Subject: signaling in draft-kompella-mpls-bundle-04.txt
>  >
>  >
>  >Hi Lou, 
>  >

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 21 Feb 2001 09:50:54 -0000

In summary...

- I agree with Yangguang, and this is what I intended to convey.
  LIH is NOT the field to use to identify a component link.
- I agree with Fong that identifying a component link in a 
  unidirectional or bidirectional LSP is not entirely clear
  from the drafts.  However,
  - on a hop-by-hop basis we have everything we need from the
    bundling draft
  - from the perspective of the ERO there are three options
    - number the component links and use the IP addresses
      as the hops in the ERO
    - consider the component links as unnumbered and use the
      extensions from draft-ietf-mpls-rsvp-unnum and
      draft-ietf-mpls-crldp-unnum to identify the links
    - GMPLS introduces explicit label subobjects in the ERO,
      these are generalized labels and are strictly for the
      interpretation of the LSR that the hop identifies - 
      they could easily encode a component link id if that 
      is what you need/want
    I favor the third option.
Note, however, that many people consider it a private and local
matter how an LSR chooses which component link of a bundle to 
use for a particular LSP.  If the LSR wanted it to be a public 
matter it would advertise the components of the bundle as 
distinct links (and we would then use option 1 or 2, above).

Adrian

>From: Guangzhi Li [mailto:[email-masked]]
>Sent: Tuesday, February 20, 2001 10:22 PM
>To: Yangguang Xu
>Cc: Zaffire - Fong Liaw; [email-masked]'
>Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt
>
>
>Hi,
>
>I agree with Yangguang. There are some confusion between IP 
>networks and transport
>networks.
>(1) IP network signaling is in-band but most transport 
>signaling is out-band or
>out-fiber. For transport network, there is a "separate" 
>signaling network.
>(2) IP network LSPs are fundamental uni-directioanl but most 
>transport network LSPs
>are bi-directional.
>(3) IP network bi-directional LSPs need two labels but most 
>transport network
>bi-directional LSPs only need one label. Of course it is due 
>to engineering design
>not fundamental requirement.
>(4) Careful thinking and design are required if a signaling 
>protocol combines them
>together, such as GMPLS ......
>
>-- Guangzhi
>
>
>Yangguang Xu wrote:
>
>> Fong,
>>
>> My point is LIH is not the right place to put interface ID 
>or Port ID. LIH
>> should be used to specify control plane signaling interface 
>ID NOT data plane
>> transport interface ID.
>>
>> As for the port ID/or component_interface_ID, it should be 
>part of a Label. The
>> definition of label in current GMPLS-Signaling functional 
>spec. is incomplete. A
>> label should be associated with a specific switchable data 
>flow (my definition).
>> Port ID + channel ID together form a meaningful unit. 
>Separating them into two
>> objects is not necessary. The procedure is that (1) source 
>node computes ERO in
>> logical link/bundle level of granularity (2) Each 
>intermediate node specifies
>> the exact physical interface (the label) for connection 
>creation according to
>> ERO and local information
>>
>> BTW, there seem to be some misunderstanding of 
>bi-directional LSP creation in
>> transport network. In SONET/SDH transport network, (and also 
>IP, ATM switches)
>> ports are normally bi-directionally identified (which means 
>one port ID actually
>> indicates two physical ports, one IN, one OUT). So a label 
>has bidirectionally
>> itself. If all ports within a network are bi-directionally 
>identified, for a
>> bi-directional LSP, only one bi-directional label is needed. 
>Upstream label,
>> from concept to implementation, is a redundancy.
>>
>> Regards,
>>
>> Yangguang
>
>
>