Re: [CCAMP] I-D Action: draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

[[e-mail]]

Hi Sergio,

Thank you for your comments.
Following is my response. 
Hope them be clear for your confuse.

Xihua


"BELOTTI, SERGIO (SERGIO)" <[e-mail]> wrote 
2011-07-20 PM 10:55:35:

> Hi Xihua,
> 
> I read the draft and I found it , as the first time, very 
> interesting but a little unclear in some points.
> Chapter 2.2.1
> You say that boundary node “could” not determine which kind of ODUk 
> FA-LSP should be triggered but you do not put any brief explanation 
> of that. I think for completeness some words should be usefull.
> 
[Xihua]: Agree. We will add some supplement for this point.
If there is no any explicite ODUk signal type indication in signal message 
or local configuration,
boundary node don't know which type of FA-LSP should be triggered.
In a word, as lack of explicite information, so boundary node (e.g., B) 
could not determine 
which kind of ODUk FA-LSP should be triggered for e2e ODU0 LSP.

> Chapter 3.2.1 
> Not clear the sentence about L bit : MUST be included vs. SHOULD be 
> included . I suppose you mean SHOULD not be included , Correct ?
> 
[Xihua]: No, it isn't.
Sometime, source node may not completely control the whole e2e LSP 
creation.
It may indicate there are several choices for boundary node to select. 
Source node has to indicate they should be included rather than "must" 
during signaling.
So boundary node may select one of choices.
That's why we define two value of L bit. 
"Must" means there is only one choice.
If there are several choices, for each element, it "should" be included.

> Chapter 3.2.3
> In chapter 3.2 you mention the possibility by ERBO to signal : FA 
> nodes end points, and FA/component link.
> Is the signal type sub-object devoted to this second scope ? I f 
> yes, why named it explicitly (e.g. FA signal type ) and not just 
> signal type , that is a little misleading. I would avoid the terms 
> sub-layers already discusse in the mailing list since there is a 
> different terminology and meaning for that in ITU. Let’s say level 
> multiplexing or something along this lines.
> 
[Xihua]: The signal type is used in OTN/SDH multi-layer network. 
It is used to explicity inform boundary node which ODUk or STM-x FA-LSP 
should be triggered for ODUj LSP (k>j).
In this case, ERBO will include a pair of boundary nodes and signal type.
For example, in the following figure, ODU3 or ODU2 FA-LSP could be for 
ODU0 LSP.
If PCE determine ODU3 must be used for ODU0, there is a ERBO in path 
message including node B, ODU3 signal type and node E.
So ODU3 FA-LSP should be triggered or ODU3 FA TE link should be selected.
|--------------------ODU0 LSP------------------|
A                      B                                E       F
o--------------o                                o--------------o
                            \                            /
                              o---------------o
                              C                        D
                         |------ODU3-------|
                         |------ODU2-------|

We will avoid using sub-layers in the next version draft.

> Chapter 3.2.5
> Not clear the sentence related to ERO : “If it is necessary , it 
> must also extract the server layer/sub-layer routing information 
> form ERO based on a pair of node. “ Could you clarify . 
> 
[Xihua]:  Based on the previous figure, ERO in path message includes 
A-B-C-D-E-F and associated interfaces. 
ERBO in path message includes node B, ODU3 signal type and node E. 
When intermidate node (i.e., B) receives path message, it will know it is 
a real boundary node of ODU3 FA-LSP in terms of ERBO.
After node B determine other edge (i.e., E) of FA-LSP, 
it will extract the routing information (i.e., B-C-D-E) from ERO to 
trigger ODU3 FA-LSP creation.

> Chapter 3.3.1 and others :
> L bit field : again the is the sentence Must be excluded vs Should 
> be avoided . I do not believe a good idead permit anyway to use one 
> resource that I’m considering to be excluded . I mean: it implies in
> case the SHOULD usage an interworking problem, right ?
> 
[Xihua]: L bit in this draft inherits from rfc4874 and rfc6001. 
Please refer to the section  "3.1.  EXCLUDE_ROUTE Object (XRO)" in 
rfc4874.
"...to indicate that an abstract node MUST be excluded (value 0) or SHOULD 
be avoided (value 1).
The distinction is that the path of an LSP must not traverse an abstract 
node listed in the XRO with
the L bit clear, but may traverse one with the L bit set. 
"

> Thanks
> 
> Sergio
> 
> 
> 
> Da: [e-mail] [mailto:[e-mail]] Per conto di 
> [e-mail]
> Inviato: mercoledì 20 luglio 2011 6.15
> A: [e-mail]
> Oggetto: Re: [CCAMP] I-D Action: draft-fuxh-ccamp-boundary-explicit-
> control-ext-03.txt
> 
> 
> Hi All, 
> 
> We updated this draft. 
> We added some new sections, suchs as the "requirement 
> identification" and "boundary nodes determination mechanism". 
> Some content are related to OTN multi-layer scenarios. 
> If you review and have some comments, pls let us know. 
> 
> Xihua 
> 

> 
> [e-mail] 
> 发件人:  [e-mail] 
> 2011-07-08 下午 07:54 
> 
> 请答复 给
> [e-mail]
> 
> 收件人
> 
> [e-mail] 
> 
> 抄送
> 
> 
> 
> 主题
> 
> I-D Action: draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
>                 Title           : RSVP-TE Extension for MRN/MLN 
Application
>                 Author(s)       : Xihua Fu
>                          Qilei Wang
>                          Yuanlin Bao
>                          Ruiquan Jing
>                          Xiaoli Huo
>                 Filename        : draft-fuxh-ccamp-boundary-
> explicit-control-ext-03.txt
>                 Pages           : 16
>                 Date            : 2011-07-08
> 
>   [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN).
>   [RFC4206] introduces a region boundary determination algorithm and a
>   Hierarchy LSP (H-LSP) creation method.  However, in some scenarios,
>   there must be some additional information to facilitate hierarchy LSP
>   creation.  This document extends RSVP-TE to meet this requirement.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fuxh-ccamp-boundary-
> explicit-control-ext-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-fuxh-ccamp-boundary-
> explicit-control-ext-03.txt
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt